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

[( Marc A. Lehmann )]

On Thu, Jun 17, 2004 at 01:57:36PM -0400, "Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> wrote:
> Given that time_t has been a 32-bit entity since day one of UNIX, there are

It's not on a lot of existing UNIX systems, where it already is 64 bit.

> a slew of binary executables out there that are built on the premise, as

Binary executables are not a problem, as ABI changes are rare. It's no
problem to support both 32 and 64 bit time() calls on the same system,
even within the same executable. This is already standard practise.

> well as plenty of values stored in disk files (take UNIX accounting logs,
> please).

The example is mostly a non-issue, as it ahs been dealt with in existing
implementations (quote databases are another - bad - example). Databases
are a bigger concern, but there are very few (if any) database systems
that directly store time_t as it is. One of the reasons is that portable
rpogramming always required to allow for different time_t representations.

> That makes it an extremely bad idea to redefine time_t as a 64-bit

I very much disagree here with you. It might be helpful to some people
to keep it a 32 bit value, but the problem needs to be dealt with before
2038, wether time_t is 32 bit or not, because at that point it will
wrap, so any databses still based on 32 bit time_t's WILL have to be
reworked.

In essence, I think your proposal to force it to 32 bit is very harmful
as it encourages problems similar to Y2K.

Most existing programs don't need changes to work with a 64 bit time_t
now, they just need to be recompiled. Forcing extra (and non-standard)
calls means every program must be changed.

> 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

The reaosn was that the units was changed, so the filesystem call was
incomaptible.

Even early unix had no problem with having two seek calls, one for 16 bit
and one for 32 bit. So they could have kept the name. The name was changed
because the sematic had changed.

To the contrary, the 32->64 bit transition many years ago involved no such
adition of extra syscalls or functions - all you need is to recompile your
program under the new environment and it can do 63 bit I/O, except when
it has bugs (which would in turn result in a 32 or 31-bit-capable program
only, which wouldn't be worse).

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

I think this is a very bad decision. It's exactly the same bad decision
as the decison that "two digits are enough to represent a year, so don't
encourage the support of 4 or more digit year values in this datatype".

-- 
                The choice of a                              |
      -----==-     _GNU_                                     |
      ----==-- _       generation     Marc Lehmann         +--
      ---==---(_)__  __ ____  __      pcg at goof.com         |e|
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/   --+
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE            |
                                                           |