Thanks for that reply on UTC etc.
As a Unix programmer, what I would have liked is for the
clock in the palm to always be kept internally as UTC,
and then have a global varaible somewhere, called TZ or something,
which is the local time offset from UTC.
Then the user always gets a converted value, and
applicaitons can have access to both times -- UTC by looking
directly at the clock, and local time by adding the TZ offset.
This is the best6 of all possible worlds.
Nobody loses out of this.
It would be enormously beneficial for those people who want to
write software that records absolute time, which does not
get mucked up by users modifying the clock every time they
cross a border.
(I remember once I visited a mexican restaurant in Gary, Indiana,
with some mathematician colleagues, who were all US citizens,
and we waited to get asked to leave the restaurant at closing time,
and nothing happened. Then we realised that Gary was not
participating in daylight saving time. Even the locals from
Kentucky and Indiana were as perplexed as poor alien me.)
How can anyone measure intervals between events unless they
have a UTC clock?
With the current time manager, I will have to ask the user of my app
to inform me of TZ changes, and adjust back to determine
the UTC from that. This is because my software _must_ now the
time elapsed between two events.
Surely I am not the only programmer who wants this?
Cheers,
Alan Kennington.
