Re: Fix p_secstodate overflow handling (bug 22463)

[Paul Eggert <eggert at cs dot ucla dot edu>]

On 11/21/2017 03:35 PM, Joseph Myers wrote:
> 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.

Sorry, I'm not quite following. Surely you don't mean that p_secstodate 
should have time-dependent behavior, i.e., that it should call 
clock_gettime or equivalent in order to determine whether the requested 
timestamp is in the 68-year window around the current time, so that it 
can generate the YYYYMMDDHHMMSS format.

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

Yes, we're agreed that the RFC does not specify an API. However, the API 
is intended for use in generating strings that follow the RFC-specified 
format, and that's all that the API has to do. I see little point to 
bikeshedding this API to try to support values outside the 32-bit range; 
doing that is more likely to cause trouble (because it will generate 
either nonconforming or numerically-incorrect strings) than to cure it.