Re: mktime.c fixes (part 2 of 6): don't reject pre-1969 timestamps

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

Ulrich Drepper <drepper@redhat.com> writes:

> These interfaces are ill-designed and should not be used for
> anything but the bare minimum.

mktime, localtime, localtime_r, gmtime, etc. are indeed ill-designed,
but they are standard and are widely used by programs since there are
no standard alternatives.  glibc should continue to support these
functions as well as it traditionally did.


> There is no requirement in the size of time_t.

True.  For example, glibc could insist that time_t must be only 32
bits even on native 64-bit hosts like x86-64.  Such behavior would
conform to POSIX.  However, it made a lot more sense for glibc to
extend POSIX, and to support 64-bit time_t on such hosts.  That way,
glibc can support time stamps past January 2038 on such hosts.  The
standard doesn't require this extension, but it is clearly a good
thing.


> >   (2) whether times are normalized before or after any overflow checking.
> 
> Then implement this with the absolutely minimal patch.

I submitted the shortest patch I know of in
<http://sources.redhat.com/ml/libc-alpha/2003-12/msg00244.html>.
The patch deletes 14 lines from the mktime.c source code.  It's a
simple patch, it obviously fixes glibc's normalization bug (please see
<http://sources.redhat.com/ml/libc-alpha/2004-01/msg00001.html> for
the test case illustrating the bug), and it's "absolutely minimal" in
the sense that it merely reverts glibc behavior back to what it was
before April 2002.

You objected to the patch because you don't want to get into the
business of supporting negative time_t values.  However, since I've
volunteered to support them, this objection isn't a strong one.

Do you have any other objections to the patch?  If not, I suggest that
we install it and then continue to the other pending mktime issues.
If so, please state the objections.

For example, if you have a test case illustrating why the patch causes
some other bug, that would be a sound objection, and I would like to
adjust the patch to fix any such bug.  (Ideally you would have such a
test case somewhere, since the patch merely undoes mktime.c changes
you installed in April 2002, and these changes must have been
installed for a reason that can be reduced to a test case.)