Tcl Source Code

View Ticket
Login
Ticket UUID: 913513
Title: clock scan returns wrong day in gmt
Type: Bug Version: obsolete: 8.4.2
Submitter: silpheed Created on: 2004-03-10 14:36:06
Subsystem: 06. Time Measurement Assigned To: kennykb
Priority: 5 Medium Severity:
Status: Closed Last Modified: 2004-08-19 20:47:50
Resolution: Fixed Closed By: kennykb
    Closed on: 2004-08-19 13:47:50
Description:
clock scan with gmt fails to return the proper day until 
your time zone changes to the next day.

Ex.

I am in CST and if I run a [clock scan "1600Z" ] or [clock 
scan "1600Z" -gmt true] or [clock scan "1600" -gmt 
true] during the actual time frame of 00:00Z to 05:59Z, 
it will return the previous day. It appears that the day 
elements is not getting altered based on the GMT time 
but by your own time zone instead. Included is a test 
file that was run on the hour for several hours that 
shows the problem.
User Comments: kennykb added on 2004-08-19 20:47:49:
Logged In: YES 
user_id=99768

Full fix implemented in 8.5

kennykb added on 2004-03-10 23:17:50:
Logged In: YES 
user_id=99768

(Partial) fix committed to the HEAD; [clock scan 1600 -gmt true]
will now return the correct date in any time zone.  The full fix
(where an explicit time zone is specified) is incompatible with
the current parser (base time is broken into fields before the
time zone is parsed); for this reason [clock scan 1600Z] will
still fail.

kennykb added on 2004-03-10 22:31:43:

File Added - 79593: badclock.tcl

Logged In: YES 
user_id=99768

Problem verified on Win2k. Thanks for reporting
the bug clearly enough to allow it to be
reproduced.

A workaround is to supply a date explicitly to the 
[clock scan].

The attached script, "workaround.tcl" shows a 
minimal exampleof the problem and how to work
around it.

silpheed added on 2004-03-10 21:40:51:
Logged In: YES 
user_id=963204

Hit submit too soon. What I am expecting is that clock scan 
would return the proper seconds for the gmt day because I 
am running a GMT based scheduler that would kick off all of 
events at the beginning of the GMT day no matter the actual 
scheduled time b/c of this problem.

silpheed added on 2004-03-10 21:36:06:

File Added - 79578: TEST

Attachments: