ml>> oops, forgot to add...

 ml>> 2003 - 1900 = bad year number of 103 and many of us have seen that
 ml>> one... its one of the date problems in bluewave and many fidonet
 ml>> message manipulation software...
 ml>> it should'nt have been a subtract but a MODulus (aka clock
 ml>> arithmetic)...

 LE> Except that it's not a programmer written function it's a
 LE> built-in function in C. dtime or some such.

hehe, yeah yeah... i wasn't thinking of programmer written functions as
seperate from library provided functions... the libraries were written by
programmers, afterall...

 LE> Ah. found it. gmtime. It returns the following variables:

 LE> tm_sec          second (0-59)
 LE> tm_min          minute (0-59)
 LE> tm_hour         hour   (0-23)
 LE> tm_mday         day of month (1-31)
 LE> tm_mon          month (0-11)
 LE> tm_year         year-1900
 LE> tm_wday         day of week (0-6) (Sunday = 0)
 LE> tm_yday         day of year (0-365)
 LE> tm_isdt         if non-zero, daylight saving time is in effect

yup... [checking] haha, i duplicated that in my pascal version it... it
does add and subtract 1900 in certain places... IIRC, i realized at that
time that it should have been MOD 100 but decided against "fixing
it" due to the reason for creating the pascal equivelent...

 LE> This function is part of *standard* C, found on Unix systems,
 LE> and in ANSI C.

 LE> It's also the only "standard" function that provides the data
 LE> in this manner instead of as a string.

yup, yup...

 LE> So as I said yesterday, it's not a matter of the programmer
 LE> doing the math wrong, it's a matter of not reading the docs.

that's true, too...

 LE> Whatever the reason was for writing the function that way back
 LE> in the mists of time, it's way too late to change it now.

welllll... yes and no... if it were me, i would either fix it or
"override" it with one that works properly... the biggest thing,
other than reading the docs on the routine/structure is that the coders
didn't stop and think about what they were reading... it specifically
states "year - 1900"... they didn't go far enough and see that
2003 - 1900 == 103... those coders who just took that number directly
should have seen that and then run a MOD 100 on /that/ result... in other
words, they didn't think far enough...

 LE> Me, I try to make sure I read *all* of the info about a
 LE> function before I use it in a program. Saved me from
 LE> trouble many a time.

know that feeling... in fact, i've been known to write specific test
procedures to check things before putting them into production code...

 LE> The programmers *assumed* that tm_year was year mod 100.
 LE> 

that or like i just stated, they didn't think far enough...

)\/(ark