64-bit time_t must go--this is non-negotiable
WHarms at bfs.de
WHarms at bfs.de
Sat Jun 19 07:36:04 UTC 2004
i see that a log of systems have moved to 64bit time_t (not only
native 64bit systems). what happends if zdump move to mytime_t 64bit ?
on 32bit that would extend the precission without any effect while
64bit system will be coverred automagicly.
(hopes to ease fustration for ado :)
- - - - - - - - - - - - - - Original Message - - - - - - - - - - - - - -
From: Paul Eggert <eggert at CS.UCLA.EDU>
Subject: Re: 64-bit time_t must go--this is non-negotiable
Date: 06/18/04 23:29
Robert Elz <kre at munnari.oz.au> writes:
> Certainly it isn't correct to simply cite the precedent of some
> other (different) change, and act as if that was sufficient
> justification for any new change.
Sure. But here we've already seen precedent for this exact same
change. Lots of operating systems have decided to use 64-bit time_t
on 64-bit hosts. They all had their inevitable shakeout period. One
(Tru64) distinguishes between time_t and time64_t, the way that ado
proposed, but as far as I can tell, nobody else thought that the extra
complexity is worth the hassle.
These folks have already made their decision, in some cases many years
ago, and they're unlikely to change their minds now no matter how much
huffing and puffing we do. If we want to write code that is portable
to 64-bit GNU/Linux, Solaris, FreeBSD 6, Microsoft Windows, etc., then
we have to make sure it works with 64-bit time_t.
> I can't imagine wanting to know about times that stretch from 1970
> to 1970 + 2.6 * 10^11, that's just absurd.
I agree, and if we had to do it over again I'd design time_t
differently, but it's too late to change this for the systems
More information about the tz