Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#4107 clock command doesn't reflect Windows time zone changes

obsolete: 8.5.3
open
Kevin B KENNY
5
2009-10-29
2008-08-13
Ingemar Hansson
No

In a running tclsh the clock command does not recognize a time zone change. Threads created after the zone change will reflect the new time zone.

Ex:
% clock format [clock seconds]
Wed Aug 13 19:26:15 CEST 2008

Now change time zone and issue the above command again. The output is the same (except for a few added seconds).

The command
% thread::create {puts [clock format [clock seconds]]}
will provide correct output time

Restart tclsh and run the command. The correct time is shown.

Discussion

1 2 > >> (Page 1 of 2)
  • Don Porter
    Don Porter
    2008-08-13

    • labels: 105657 --> 06. Time Measurement
    • assigned_to: dkf --> kennykb
     
  • Logged In: YES
    user_id=496139
    Originator: NO

    In unix, "changing the time zone" doesn't make sense globally. Instead, the timezone is a per-process thing associated with the value of the TZ environment variable. In addition to that, unix has no such thing as setting another process's environment from the outside. So it seems hard to define a portable interpretation of a system-wide change of "the" timezone.

    Now are you saying that you're setting ::env(TZ) from the inside, and complaining about [clock]'s init code note being re-run on that occasion ?

     
  • Logged In: YES
    user_id=238112
    Originator: YES

    I'm awfully sorry, I hate incomplete error reports, and here I am filing such a beast myself ... :-(

    I forgot to mention that this happens in Windows Vista. No TZ environment variables are set.
    I also should mention that it works as expected in Tcl 8.4 (I guess this has to do with the major rewrite of the clock command in 8.5)

     
    • status: open --> pending
     
  • Logged In: YES
    user_id=496139
    Originator: NO

    OK, in Windows you're right it is different in the absence of $::env(TZ).
    Here another consideration comes to play: performance. See the comment in library/clock.tcl:

    # GetSystemTimeZone --
    # Stores the sustem time zone in the 'CachedSystemTimeZone'
    # variable, since determining it may be an expensive process.

    A simple workaround for you is then to unset ::tcl::clock::CachedSystemTimeZone before each of your calls to [clock format].
    I think the trade-off is well chosen considering the rarity of timezone-tracking apps wrt simple apps who just want to display a time, and do it fast (because they are just logging timestamps for some quick event for example). For this reason I'm switching this to Pending. Feel free to kick it open again if you feel other argumentation is due.

     
  • Logged In: YES
    user_id=238112
    Originator: YES

    The suggested workaround is fine with me. I need it in app that checks that noone tampers with the system time.
    Thanks a lot!

     
    • status: pending --> open
     
  • Logged In: YES
    user_id=496139
    Originator: NO

    Kevin, do you agree to leave things the way they are, and close the entry, or would you like to re-evaluate the cost of calling GetTimeZoneInformation et al. ?

    -Alex

     
  • Kevin B KENNY
    Kevin B KENNY
    2008-08-25

    Logged In: YES
    user_id=99768
    Originator: NO

    Sorry about the delayed response, it's vacation time here...

    One thing that would be possible, if the message pump is going, would be to intercept the WM_SETTINGCHANGE message, and use it to trigger clearing the cached time zone. This should incur run-time cost only when the time zone changes (and at initialization).

    This approach would require each interpreter that has 'clock.tcl' in place to have an async notification window to receive the message and process it. This is a bit nasty, since we don't yet have anything in place that handles notifications at this sort of global level. If you're interested in pursuing this approach, tclWinDde.c and tclWinSock.c both have code that creates a notification window (in the one case, to handle DDE messages, in the other, to trigger events on sockets).

    Since time zone change is such a rare event, I didn't think it was worth the effort to do this stuff at the time I implemented [clock]. If this becomes a recurring complaint, perhaps we should revisit the decision.

     
  • Logged In: YES
    user_id=496139
    Originator: NO

    Yes, I had noticed the existence of that notification mechanism, but discarded it on the grounds that it needs an event loop or at least the Windows-only part GetMessage(), possibly in a separate, hidden thread... eeeek. (indeed [clock] should behave the same with or without [vwait] or Tk).

    But maybe I'm missing something else, like a callback API which doesn't need its own thread, where we could call Tcl_AsyncMark.
    Is it what you have in mind ?

     
1 2 > >> (Page 1 of 2)