On Thu, 8 Apr 1999, Laurence Lundblade wrote:

> The one thing I'd sort of beg for in PalmOS is to store dates in 
> GMT/UTC rather than local time. I much prefer this, and it is what 
> UNIX does. The actual display and input of the date is in local time, 
> but the date is stored in GMT. The user sets their local time zone as 
> a preference and that determines how the dates are input and output. 
> This makes sorting of dates (say on mail messages in my case) much 
> more reasonable. You of course store the timezone offset with the 
> date (my choice here was minutes off GMT to fit into a short as no 
> one will ever have a timezone offset in seconds - 15 minute 
> resolution could fit it into 7 bits and would also be enough).

Pardon me, but this is another one of my soapbox topics: yes, you can use
GMT, but the timezone offset is anything but trivial. It changes
seasonally (if your area uses Daylight Savings Time, or an equivalent),
and changes with the whim of politicians. (Has your country recently been
seized by a foreign power? Check your clocks!) And don't bet anything
about what particular resolution is needed, especially if you aren't
familiar with leap seconds. (No, they shouldn't affect current time-zone
calculations, but they do affect historical conversions to local-time.)

For more information on this topic, please see the archives of the
timezone mailing list, along with the only semi-official timezone database
in the world, at <ftp://elsie.nci.nih.gov/pub/>.

I certainly would like GMT, as using local time has some unfortunate
side-effects. (Such as, if you take your device between time-zones, the
various times & dates stored for database backup times, modification
times, etc., shift by several hours). Using a modem or network
synchronization across time zones can be quite confusing, especially if
you are talking to a UNIX box that does use GMT, and has a very precise
idea of "what time it is".

However, IMO a poor universal-time implementation (with limited DST
support, among other things) is more troublesome then no GMT at all. At
least with the current approach, you _know_ everything is in local-time,. 

(Also, note the difficulties involved with setting up an appointment book
to properly use universal- and local-time. Should appointments stick to
the same universal time, or should they refer to local time? If I'm
setting up an appointment to meet somebody at Noon on the other coast,
then local time is appropriate. But it's a different matter if I need to
call the boss at 2:00 PM, his time.)

-- 
Kenneth Albanowski ([EMAIL PROTECTED], CIS: 70705,126)


Reply via email to