🚀 go-pugleaf

In <541zwjlq6y.fsf@rrdjazz.nist.gov> Przemek Klosowski <przemek@rrdjazz.nist.gov> writes:
>
> will pass on 03:14:08 GMT, Tue Jan 19, 2038, even for software that
> incorrectly interprets the date as signed integer.  For correctly
> written software it will be yr. 2106 when the date will overflow.

time_t must be signed, or things like difftime wont work correctly,
and gettimeofday returns -1 on an error.

Trying to fix the problems with switching from signed to unsigned
time_t isn't worth it.  Just switch to a 64-bit time_t instead.


> The only place where you might run into trouble is because computer
> hardware clock maintains the 2-digit date, [ .. ]

no, there are *lots* of places that you can run into trouble.  All
sorts of "system" commands such as date, ls, find, touch, etc. may not
be y2k compliant (they have failed on other Unix systems...).  It is
even possible that certain device drivers could break.  And then there
are the oodles of applications that may break.  Does netscape work
correctly?  What about ntp or nntp?  Does xv write any timestamps in
anywhere?


While Unix may be much better off than other operating systems, it is
certainly not a *given* that everything will work.  If you want to be
sure that things work in the year 2000, get a machine with the
software that you want to run and *test* it during the roll over and
beyond.


-wayne



-- 
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.