This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix p_secstodate overflow handling (bug 22463)
On Tue, 21 Nov 2017, Paul Eggert wrote:
> On 11/21/2017 02:38 PM, Joseph Myers wrote:
> > Where does it say that?
>
> It's in RFC 4034 section 3.1.5, which says that the time values specify a
> "date and time in the form of a 32-bit unsigned number of seconds elapsed
> since 1 January 1970 00:00:00 UTC, ignoring leap seconds." Although section
That section is about the wire format (and clearly implies that *in the
wire format* the low 32 bits are used).
> 3.2 says how these time values are represented, it does not give license to
> represent a date and time that is out of the 32-bit range. Section 3.1.5 goes
> on to say that the intent is to use serial number arithmetic a la RFC 1982,
> which boils down to using the low-order 32-bits of the full timestamp.
My reading of section 3.2 together with section 3.1.5 would be that *when
giving a textual representation of a value from the wire format*, it's
either YYYYMMDDHHmmSS for the *actual* time (within 2**31 seconds of the
present time), as long as that involves a year from 0001 to 9999, or the
decimal value of the 32 bits from the wire.
It says nothing about what the textual representation should be for an API
that is given extra information beyond the 32 bits on the wire, such as
p_secstodate on a 64-bit system.
> I'm still thinking that it would simplify things (and avoid similar confusion
> in the future) if p_secstodate always used sprintf ("%u", ...) for these
> timestamps.
I think that would be contrary to the point of this API for use in
debugging, which means it should give a more human-readable output when
possible.
--
Joseph S. Myers
joseph@codesourcery.com