Re: Fix p_secstodate overflow handling (bug 22463)

[Joseph Myers <joseph at codesourcery dot com>]

On Tue, 21 Nov 2017, Joseph Myers wrote:

> On Tue, 21 Nov 2017, Paul Eggert wrote:
> 
> > I reread the RFC, and found that our patches both mishandled out-of-range
> > timestamps. The RFC says that, for a timestamp greater than the 32-bit range,
> > the string should be a decimal representation of the timestamp's low-order 32
> > bits. With this in mind we can simplify the fix since we need not worry about
> 
> Where does it say that?  My reading is more that (a) the binary 
> representation is the low-order 32 bits; (b) a decimal representation of 
> the low-order 32-bits is valid as a textual representation, but (c) the 
> timestamp is to be interpreted as whatever time with that low-order 
> 32-bits is within 68 years of the present, and so a YYYYMMDDHHmmSS 
> representation corresponds to that time.

And, incidentally, I don't see how any of this can say anything about what 
the API should do for values outside the 32-bit range, since the RFC is 
purely concerned with interpretation and representation of values *within* 
the range, as those are all that can be transmitted in the DNS protocol.  
So if a time value outside the range is passed, it seems to make logical 
sense to produce the most human-readable representation, i.e. 
YYYYMMDDHHmmSS when possible (while recognizing that this API is 
problematic post-2038, as then the value 0 on the network should no longer 
be interpreted as in the year 1970).

-- 
Joseph S. Myers
joseph@codesourcery.com