64-bit time_t must go--this is non-negotiable

[Paul Eggert]

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
mentioned above.