Re: CF 1 Setting time across Daylight Saving Boundary Issue

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I've just run through a simple test where I send a new local time (local
time is what's stored in the system clock), to one of our devices, then read
it back, via a Telnet server that I wrote. It works precisely as expected.
I change the time and read it back as fast as I can type "get datetime" and
it matches what I set plus a second or two. Changing to a time that is
after the next DST transition does what I'd expect (although I doubt that
it's documented anywhere), changing the time forward or back an hour to
account for the DST change and changing the DST flag returned by
GetTimeZoneInformation().

My guess as to the source of this problem with the DateTime class is that
it's probably caching the DST flag and, therefore, using the wrong offset to
calculate the current time, somehow. I don't know why it would be using the
system time and offsetting it, rather than just reading the local time
directly, but that's what it seems to do, resulting in inconsistent
behavior. If it just returned the result of GetLocalTime(), everything
would match up perfectly, I think.

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:uDVfjRQgGHA.4304@xxxxxxxxxxxxxxxxxxxxxxx
Maybe expected is too strong a word. Known, maybe.

I do SetSystemTime() all over the place and the clock is always fine. I
have a number of utilities which conspire to set the time under user
control and allow it to be read back, all with SetLocalTime/GetLocalTime
and there's never been a test failure that I can remember.

When there's a change in the DST flag performed by the shell, at least the
standard, non-Pocket PC shell, in Windows CE, SetLocalTime() is called to
make that change and a check for DST is done on every time zone change and
manual date/time change, as well as when the next transition time rolls
around. That is, there are three events detected: user changes time zone,
user changes time, and clock reached time to go from DST to ST or vice
versa. The shell always just uses GetLocalTime() to retrieve the time, as
far as I can tell and never does anything as far as display with the time
zone, calculating anything, or even knowing whether DST is active or not.

Paul T.

"K G O''''Connor" <KGOConnor@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:12C238F7-4D5E-4F87-815B-83E4DE00874A@xxxxxxxxxxxxxxxx
Thanks again, Paul,

Since you indicate that you think it is expected, do you know if there is
a
bit of documentation or KBase on this that I might have missed?

I'm also curious as to why you think it is DateTime.Now that has the
problem
and not the OS. I think that I was calling SetSystemTime and
SetLocalTime
with structures that ought to yield the same result, but as you can see
in
the little program, that is not the case. If I didn't mess up those
calls,
then it indicates to me that there is an OS problem rather than a
DateTime.Now issue. Am I missing something?

Also there seems to be another problem demonstrated by the little app.
The
title bar clock seems to check for the daylight savings flag only when
the
time is updated by Set(System|Local)Time, but after a little while the
daylight savings flag changes (to the appropriate value based on the date
and
time) however the clock never looks at that flag again (or never gets
some
signal that it changes) and stays out of whack. Well :-) at least that
is
what it seems from the outside looking in.

Kevin

"Paul G. Tobey [eMVP]" wrote:

Yes, that's expected, I think, although not necessarily right.
DateTime.Now
is the problem, not the OS itself. You can easily confirm that with a
native-code application, of course. As to why, I don't know. You can
always P/Invoke GetLocalTime/GetSystemTime, just to verify that...

Paul T.

<snip>




.

Relevant Pages

  • Re: NTP Configuration for DST?
    ... OpenVMS systems usually have the system clock set to local ... The time NTPD comes up with is converted to local time (using ... We do this using zone and DST information already present in our ...
    (comp.protocols.time.ntp)
  • Re: system clock is too slow
    ... >> the clock hasn't been saved to the hardware clock. ... > DST) is then just an OS setting. ... > and do the offset yourself when you need local time). ... One subtlety I just discovered is that in Windows, ...
    (Fedora)
  • Re: No daylight bit, apparently
    ... button, it listens for WWVB at 0100, 0300 and 0500 local time. ... 0100 WWVB is still broadcasting the DST flag, so if it syncs on the ... I would think that the DST flag would be keyed to UTC. ... I'd guess your clock doesn't have the ``remembering'' part perfect. ...
    (sci.geo.satellite-nav)
  • Re: how to change date of system
    ... time for DST, and ending up an hour out? ... Linux doesn't do that. ... the world that observe DST (at least for those who set their HW clock to ... local time), and I'm sure that's *not* what you mean. ...
    (Debian-User)
  • Re: Getting GMT time
    ... Anonymous AtWork wrote: ... but what about DST when it is 6. ... Look at the clock man page, especially where it mentions the -gmt ... Given the local time, I want to know the GMT time. ...
    (comp.lang.tcl)