🚀 go-pugleaf

gordon@sys-2-34.multitone.co.uk (Gordon Scott) writes:

> Chris Waters (cwaters@systems.dhl.com) wrote:

> : As for the 2038 end-of-epoch, I think we can safely wait till at
> : *least* 2001 before we start to panic.  :-)

> Smiley noted ;-).
> There are a few other end-of-epochs that have given problems
> already, fortunately not in Linux which seems cleaner than some.
> However, many of us are are under pressure to make an "It's y2k
> compliant" statement on many diverse tools, products and packages.

Yup, I certainly have been.  Which is why I want to wait till at least
2001 before dealing with less pressing time-related issues.

> : (There *are* plans already in place for migrating to a 64-bit time_t.)

> Yup. Again, personally, I think we should be dealing^H^H^H^H^H^H
> have dealt with both together -- why fix two related problems
> separately?

Ah, ok, there's definitely something to that argument.  But I'm not
sure it's that easy.  Plus, while it may take less time to fix both
problems if you fix them both at the same time, it will still take
more time to fix both than it will take to just fix one.  And only one
is in danger of exploding in our faces.

Also, I suspect that 64-bit hardware will become the norm fairly soon,
and 64-bit time_t will probably fall out as a natural consequence of
that.  IOW, unlike most y2k problems, the UNIX end-of-epoch problem
may actually fix itself, to a large extent, without the need for
anything more complex than "make all".

cheers
-- 
Chris Waters             | Bill Gates: "We need room to innovate!"
cwaters@systems.DHL.COM  | 
xtifr@dsp.net (personal) | Me: "Well, that would certainly be a change."
www.dsp.net/xtifr/ (web) |