Re: Y2k Compliance - there's a topic here?

Ethan (
Tue, 4 May 1999 16:45:05 -0700 (PDT)

On Tue, 4 May 1999, Andrew Sullivan wrote:

> Ethan's remarks interested me, because I recently took responsibility for
> a library's systems, including an HP-UX box.  Turns out HP-UX 10.20 is not
> compliant, but I don't seem to be able to find out exactly how.  There's
> just this big pile of patches that they're offering.  (Fortunately (!?),
> our automation system provider is one of those, "You don't need to know,"
> types.  So I don't have to do the work, I just have to clean up if it
> breaks.  What a good deal!  Eeeuughhh.)

Best way to test is to change the system date to 2000, restart, and see 
if it still works.  I remember testing this way on my linux box a while 
back; it was amusing because while I could set the date forward, I 
couldn't just as easily set it backwards again...

> So, there's a meta-question to Scott Carlson's question: is there any way
> that X or its children interact with date-conversion functions?  I'm not
> worried about running out of bits for the seconds since 1970; rather, I
> want to know (in case anyone knows) whether any (various) bits manipulate
> the date _after_ conversion.
> So, is Ethan still right in this case?  (My impression is, "Yes."  But
> what do I know?)

The standard C (and thus UNIX) functions for manipulating dates are as 
Y2K compliant as possible.  That is, they allow two-digit years if the 
programmer is foolish enough to want that format.  The usual technique 
is to manipulate dates in terms of seconds since some arbitrary start 
date, then use a conversion routine before display.  This means the 
dangerous date is not 2000, but 2038 or so.

As an interesting test case, take XFree86 on my x86 linux box.  It 
counts time not in seconds, but in 100th's of seconds.  The rollover is 
thus every 248 days.  If AfterStep is left running this long (or just 
happens to hit the rollover), strange things happen.

Ethan Fischer