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

[Olson, Arthur David (NIH/NCI)]

Given that time_t has been a 32-bit entity since day one of UNIX, there are
a slew of binary executables out there that are built on the premise, as
well as plenty of values stored in disk files (take UNIX accounting logs,
please). That makes it an extremely bad idea to redefine time_t as a 64-bit
value.

This does not, of course, mean that it's a bad idea to have 64-bit time
stamps available--as long as they're available under a different name (along
with differently named functions to manipulate them). The historic precedent
in the UNIX realm is the addition of the "lseek" system call once files got
larger than good old "seek" could handle (even with the provision of seeks
where the short-integer seek argument specified a block number rather than a
byte number). So somewhere down the road we can expect to see entities such
as ltime_t and lgmtime.

Bottom line: we should probably not be doing a lot of work to support 64-bit
time_t implementations since we don't want to encourage such
implementations.

				--ado