I always thought the 2038 date limit of UNIX, MacOS, etc. was mostly
because no one worried because it was so far in the future and
storing the # of seconds in a 32 bits is very very convenient. If my
math is right the difference between UNIX and PalmOS is that UNIX
uses a signed quantity and PalmOS/MacOS an unsigned. I'd guess the
1904 date was picked (by Mac folks) because it was convenient in the
# of seconds and it avoided the year 1900 in which requires another
leap year exception calculation (we're lucking out in that 2000 is an
exception to an exception and thus the normal leap year rules work).
Some UNIXes added microseconds in an additional long to the date
functions available, but they still die in 2038. It's kind of too bad
they didn't use the extra bits and establish some convention we could
coat-tail on. In reallity half a dozen more bits would be fine for
all but astronomers and geologists.
I can't see the amount of space taken up by date storage as an issue
any more on any platform. It certainly isn't worth the pain,
suffering and extra code involved in dealing with its limitations
(unless you're a y2k opportunist).
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).
LL
