hi list, 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 :) walter - - - - - - - - - - - - - - Original Message - - - - - - - - - - - - - - From: Paul Eggert <eggert@CS.UCLA.EDU> Subject: Re: 64-bit time_t must go--this is non-negotiable Date: 06/18/04 23:29 Robert Elz <kre@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 mentioned above.