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:

> Paul Eggert wrote:
> > This patch undoes a hack installed in glibc's version of mktime in
> > April 2002,
> 
> I don't even want to get into the business of supporting arbitrary dates.

You don't have to worry about getting into that business
(as I'm willing to support mktime :-).

Besides, this is not merely an issue of whether mktime should support
negative time_t values.  POSIX requires that mktime must work properly
with dates that fall into the current epoch after normalization.

For example, POSIX says that the program at the end of this message
must print "time = 0 1970-01-01 00:00:00", but with current glibc it
prints "time = 4294967295 1968-12-397 00:00:00".  For chapter and
verse, please see
<http://www.opengroup.org/onlinepubs/007904975/functions/mktime.html>,
which says "the original values of the other components [including
tm_year] are not restricted to the ranges described in <time.h>"; this
indicates that dates and times should be normalized before any range
checking is done, not afterwards.

Other systems that I've tested (including Solaris 9 and OpenBSD 3.2)
do not have this bug.  The bug is fixed by the "part 2" patch.

Perhaps you put that workaround in mktime.c in response to a glibc bug
report somewhere?  If so, perhaps I can find a better solution to the
bug, one that's simpler than my "part 5" patch.


#include <stdio.h>
#include <time.h>
#include <stdlib.h>

struct tm tm;

int
main (void)
{
  time_t t;
  if (putenv ("TZ=UTC0") != 0)
    abort ();
  tm.tm_year = 1968 - 1900;
  tm.tm_mon = 12 - 1;
  tm.tm_mday = 31 + 365 + 1;
  tm.tm_hour = 0;
  tm.tm_min = 0;
  tm.tm_sec = 0;
  t = mktime (&tm);
  printf ("time = %lu %.4d-%.2d-%.2d %.2d:%.2d:%.2d\n",
	  (unsigned long int) t,
	  tm.tm_year + 1900, tm.tm_mon + 1, tm.tm_mday, tm.tm_hour,
	  tm.tm_min, tm.tm_sec);
  return 0;
}