Re: What time is it? Issues with Local time, system time, DST

On Apr 15, 11:14 am, "Paul G. Tobey [eMVP]" <p space tobey no spam AT
no instrument no spam DOT com> wrote:
Hi,

We are having difficulty figuring out what time it is when our board
restarts. Does someone have some wisdom about figuring out actual
system time following a reboot?

Apparently CE (at least CE 5.0) stores time in local time, not system
time. Apparently (based on suggestions I found in newsgroups) this was
done for speed, on the assumption that most requests to get time would
be for local time, not UTC.

So OEMSetRealTime receives, and OEMGetRealTime is expected to return,
a local time. I think (yes?) a further assumption is that the result
of an OEMSetRealTime call is that a 32 or 64 bit value representing
the current time is stored in an (internal or external) battery backed
RTC, so that when processor is asleep or off, onboard batteries
continue to power the clock and when board reboots, we determine
current time based on contents of battery backed RTC. Is this correct
so far?

No.  I'm not sure where you got that information about OEMSetRealTime
returning some big number.  It returns BOOL, as documented in the help.
OEMGetRealTime returns the current time in a SYSTEMTIME structure.  Where
you get it from, a battery-backed real-time clock, from clock registers in
the processing, which might not be battery backed, or from a satellite, is
not specified by Windows CE (it doesn't care; do whatever you want).


Sorry, I mistyped. I meant that OEMGetRealTime returns a 32 or 64 bit
value. That wasn't clear either, since it's a SYSTEMTIME, which can be
converted to a flat value (using functions available in kernel or
applications).

Since CE stores local time, I think this means that when you reboot
you can't know the UTC unless you also have, in some non-volatile
storage, the time zone *and* whether we are currently in DST or not.
So is the standard way to handle this to store time zone and DST state
to non-volatile storage? Are there standard API calls people use for
this?

The time zone which is set for the device is stored in the registry by
calling SetTimeZoneInformation.  The Date/Time control panel applet does
this under user control and there is, of course, a default value.  If your
registry is not persistent, yes, finding out UTC will not be possible on
startup, until the user has told you where he's located.  The setting of the
DST flag is also stored in the registry.  If that persists, you're fine..


Yes, thanks, that's what I thought.

A simpler solutions seems to be to just store the UTC, not local time,
at the cost of an extra conversion to satisfy CE. In this case
OEMSetRealTime would convert to UTC before storing in the non-volatile
RTC, and OEMGetRealTime would convert to local time before returning
contents of the RTC. Then to set the time on start up the board would
have to do nothing other than verify the RTC had valid non-garbage
contents. This value could be extracted directly from RTC using an
IOCTL. The time zone would still have to be stored in a non-volatile
way (so user doesn't have to reset it), but it wouldn't have to be
accessible to low-level startup code, and DST wouldn't have to be
stored non-volatile at all. I tried to implement this, but the obvious
functions to do the conversion from UTC to local time don't seem to be
linked in the kernel. Am I not using the right functions?

What would this do for you?  Seems totally useless to me.  

We have a headless device that runs from some utility closet and needs
to know what time it is when it reboots without user intervention. It
works with a server that could be in a different time zone, and so
many time configuration and calculation are done in GMT. Also, local
time sometimes has certain limitations. If you want to subtract two
time values, you cannot do it directly in local time, unless you know
there was no DST transition between them.

Windows CE, at
least anything running the standard shell, is going to ask for the local
time, to display in the system tray, very frequently.  

We don't have a shell. I figured devices with UI that people would
generally be monitoring while the device was in use was the reason for
the design.

I don't see any valid
reason why you'd want to make that process slower.   So, the question is,
"WHY?!?!" Why would you want to try to make Windows CE work in a different
way?  

It seems like determining current time on startup would be much less
of a headache, and would require reference to one piece of hardware
(RTC) not the coordination of two (RTC, flash). Our overall board was
implemented years ago and we had trouble getting registry persistence
to work well. I we were doing it over we probably would persist
registry directly in flash and save some of the headache.

You get NO VALUE from doing this unless you are constantly calling
GetSystemTime() in some application, to get UTC, which requires a conversion
from the local time that Windows CE expects to store.  If you're not doing
that, forget about doing this.  If you *are* doing that, tell us what you're
doing, how often, from what sort of code, and why; maybe we can point you in
a direction that makes sense.


It's really a question of how you figure out what time it as the
moment you boot. It sounds like generally you should persist timezone
and DST state (either through registry or otherwise), and use those to
adjust RTC if necessary on startup.

Paul T.

.

Relevant Pages

  • Re: What time is it? Issues with Local time, system time, DST
    ... Apparently CE stores time in local time, ... be for local time, not UTC. ... RTC, so that when processor is asleep or off, onboard batteries ... you can't know the UTC unless you also have, in some non-volatile ...
    (microsoft.public.windowsce.platbuilder)
  • Re: What time is it? Issues with Local time, system time, DST
    ... works with a server that could be in a different time zone, ... is expecting to be local time. ... not the coordination of two (RTC, ... implemented years ago and we had trouble getting registry persistence ...
    (microsoft.public.windowsce.platbuilder)
  • What time is it? Issues with Local time, system time, DST
    ... Apparently CE stores time in local time, ... be for local time, not UTC. ... RTC, so that when processor is asleep or off, onboard batteries ... you can't know the UTC unless you also have, in some non-volatile ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Register RTC COM Components Win CE.NET
    ... Sorry - is RTC a component in Platform Builder? ... necessary registry keys/values needed to use it (in the default registry ... >> I don't know RTC, but if it included an installer, then the installer ...
    (microsoft.public.pocketpc.developer)
  • Re: Setting The System Clock [Linux]
    ... but chrony also corrects for your rtc errors. ... it is on local time, and display that time. ... ] `chronyd' assumes by default that the real time clock keeps ...
    (comp.os.linux.misc)
Loading