Fix p_secstodate overflow handling (bug 22463)

Paul Eggert eggert@cs.ucla.edu
Tue Nov 21 23:00:00 GMT 2017


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

> the RFC is
> purely concerned with interpretation and representation of values*within*  
> the range

By referring to RFC 1982, RFC 4034 is clearly concerned with how to deal 
with timestamp values outside the 32-bit window.

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.



More information about the Libc-alpha mailing list