#3352 clock scan

[Alexander Schoepe]

Tested on Tcl >= 8.4.2

% clock scan 1970-01-01T07:00:00 -gmt 1
0
% clock scan 1970-01-01T07:00:01 -gmt 1
1

% clock format 0 -format "%Y-%m-%dT%H:%M:%S" -gmt 1
1970-01-01T00:00:00
% clock format 1 -format "%Y-%m-%dT%H:%M:%S" -gmt 1
1970-01-01T00:00:01

There is a difference of 7 hours = 25200 seconds.
Is this a bug or is there another explaination?

Regards,
alex

[Daniel Collins]

Logged In: YES
user_id=1093010

I'd noticed this before (can't remember if I logged it, or
had seen it logged already), clock scan of ISOxxxx
(whatever that number is) has trouble in 8.4.

I've seen differences of 6 hours before, what I did was to
remove the punctuation from the date and time, that seemed
to help it out.

% clock scan 19700101T070001 -gmt 1
25201

I used string map {- {} : {}} to sort out the args to
clock scan, that worked for me.

I think the "real" solution is to use the new clock scan
in 8.5, but I'm stuck with 8.4 :(

[Kevin B KENNY]

Logged In: YES
user_id=99768

I walked through this in the parser, and discovered that
in this syntax, the T is being interpreted as a
time zone indicator (!). NATO uses letters for time
zones: Z is UTC, A is UTC+1 up through M is UTC+12 (J
is omitted), N is UTC-1 through Y is UTC-12. So the
parser is interpreting the string as 1970-01-01,
time zone T (UTC-7), time 07:00:01.

This sort of thing is what you get when you have a
specification that's so fraught with ambiguity, which
is why I think that free-format [clock scan] is likely
always to have problems like this one.

Feel free to reopen this bug if you have any brilliant
ideas about how to fix this and not break something else.

[SourceForge Robot]

Logged In: YES
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).