This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: mktime.c fixes (part 2 of 6): don't reject pre-1969 timestamps
- From: Ulrich Drepper <drepper at redhat dot com>
- To: Paul Eggert <eggert at CS dot UCLA dot EDU>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 31 Dec 2003 17:24:29 -0800
- Subject: Re: mktime.c fixes (part 2 of 6): don't reject pre-1969 timestamps
- Organization: Red Hat, Inc.
- References: <87brpp1iwc.fsf@penguin.cs.ucla.edu> <3FF357E5.6010807@redhat.com> <87y8ss4hsm.fsf@penguin.cs.ucla.edu>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Paul Eggert wrote:
> You don't have to worry about getting into that business
> (as I'm willing to support mktime :-).
You completely miss the point. The interfaces in the libc are more
widely and uncontrolled used. Nobody must use them for anything and to
ensure this the interface must be restrictive.
> 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.
This is why 1969 is recognized. Epoch is 00:00:00 1970-01-01 UTC, so
only 1969-12-31 needs to be handled. Not 1968.
> 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.
I don't care about the bogus decisions made for other implementations.
No negative values for Epoch are valid. There is no requirement
anywhere that time_t is a signed type.
- --
â Ulrich Drepper â Red Hat, Inc. â 444 Castro St â Mountain View, CA â
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/83bN2ijCOnn/RHQRAjB7AJ4ovWUf52uo2rihx6BrDR2fcFdYiQCfbSMT
NIhf+1cCvjpsLSd3AhViPoU=
=I+g4
-----END PGP SIGNATURE-----