clock scan problem

[HydroBob]

I am trying to determine which date is oldest and am having problems with the
clock scan command (or don't fully understand it!). My code is as follows:

set a [clock scan $date_a]
set b [clock scan $date_b]

Where date_a is a past date and date_b is in the future. The return value for the
future date (when the years are different such as 2002 for the past and 2003 for
the future) always comes back lower than the past date. I thought the clock scan
would use the same comparison date for both past and future dates. What am I
doing wrong.

The dates I used were Nov 15 2002 and Jan 15 2003, and the return
values were 1037390520 and 1011124980 respectively.

Thanks in advance!!

 

[ulis]

You need to add a ',' before the year to obtain what you want else you get always a date in the current year.
I think it's a bug.

From the manual:
date
A specific month and day with optional year. The acceptable formats are mm/dd?/yy?, monthname dd [red]?, yy?[/red], dd monthname [red]?yy?[/red], day, dd monthname yy, ?CC?yymmdd, ?CC?yy-mm-dd, dd-monthname-?CC?yy. The default year is the current year. If the year is less than 100, we treat the years 00-68 as 2000-2068 and the years 69-99 as 1969-1999. Not all platforms can represent the years 38-70, so an error may result if these years are used.



puts [clock scan "Nov 15, 2002"]
->1037314800
puts [clock scan "Jan 15, 2003"]
->1042585200

HTH ulis

 

[AviaTraining]

Whether or not it's a bug is debatable. clock scan handles so many different formats that it's sometimes difficult to predict how a time and date string might be treated.

ulis pointed out the relevant section of the clock reference page covering how dates are treated, and as mentioned, a date string of that format needs a comma between the date and year. So this begs the question what exactly is clock scan doing with the "2002" and "2003" in this case?

For the answer to that, we need to look at the description of valid time formats:

A time of day, which is of the form: hh?:mm?:ss?? ?meridian? ?zone? or hhmm ?meridian? ?zone?. If no meridian is specified, hh is interpreted on a 24-hour clock.

In other words, with the string "Nov 15 2002", "Nov 15" is treated as the date, and "2002" is treated as the time, 20:02 or 8:02pm.

I must admit that I find this interpretation unexpected as well. It might be worth filing this as a bug just to raise the issue with the Tcl Core Team. They can then debate whether this should be the intended behavior or not. - Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[ulis]

You're true Ken, the result followed the description.
I was fooled by the two successive syntaxes:
monthname dd ?, yy?
dd monthname ?yy?

I admit it's hard to have that much versatility without some ambiguity.

ulis

 

[HydroBob]

Thanks guys. I would never have caught that.

Bob