On Thu, 8 Apr 1999, Michael Hutchens wrote:
> Well I seem to have started a bit of a firestorm with my innocent question.
> I was in fact missing the obvious -- that the year the number of years
> since 1904 (I'd been assuming it was the number of years since 1900 despite
> seeing the DateTime.h #defines a gazillion times). The result however is
> that I've done what lots of other folks did -- my program handles dates out
> to 2050 (not much of an improvement, but something) because of a lot of
> workaround programming (that section of my code is UGLY).
>
> So I'm curious now -- you can all tell that I'm a dilettante programmer (in
> my other life I'm about to be a doctor). Why can the palmOS only handle a
> 127 year span when only a few bits more could have obviated the whole
> problem? Seems penny-wise and pound-foolish.
8 bit probably would have been better..
who knows.. maybe there is more information in a date record?
it is like defining a date record like this:
struct myDate
{
int year : 7; // 2^7 = 128 different possibilities.
int month : 4; // 2^4 = 16 different possibilities.
int day : 5; // 2^5 = 32 different possibilities.
}
this means that the total space required for the date structure
is 16 bits (which is 2 bytes).
if you want to use 8, then you need 3 bytes.. having 8,9,.. or
even 15 bits for the year will still require 3 bytes.
this is a bit of C i definately know.. :)) bitwise structures.
i think PalmOS wanted to syncronise the date screwup with
Unix.. unix stores dates using 32 bit ints, and the date()
function returns the number of milliseconds since Jan 1, 1970
.. it expires in 2031.
maybe 3COM engineers were smart after all?!
when UNIX dies.. so does everything else!
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 352 8192 A/H: +46 26 10 16 11
