Third draft of the Y2038 design document

[Paul Eggert]

On 06/08/2016 06:58 AM, Albert ARIBAUD wrote:
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=63

Thanks, some comments:

The "Scope" section should clearly say that the document is only about 
Y2038 (and Y1901) and is not about other time boundaries, e.g., Y2106 
for unsigned 32-bit times, Y9999 for decimal years, etc. For example, 
asctime_r in practice might not be Y9999-safe because it may overrun a 
too-small output buffer, but this document doesn't care about Y9999 so 
it marks asctime_r as Y2038-safe.

The definitions of 32- and 64-bit time should explicitly say what 
happens during a leap second. In POSIX leap seconds are ignored; glibc 
allows you to set TZ to a value where the time stamps also count leap 
seconds. Although the rest of the document assumes leap seconds are 
ignored, I assume its scope also includes TZ settings enabling leap 
second support; this should be made clear.

Some of the API functions are marked as Y2038-safe merely because they 
use a Y2038-safe API. However, in practice they may not work after 2038 
because they use time_t internally. For example, strftime and getdate_r 
call mktime and so may not work after 2038. Shouldn't these functions be 
considered unsafe?

Some of the API symbols use time_t as a relative value, not as an 
absolute one. These APIs should still work fine after 2038. It is true 
that the APIs cannot specify relative values greater than 68 years or 
so, but this is a different issue (much as the Y2106 problem is a 
different issue). To limit the document's scope, I suggest excluding 
these symbols; but even if we decide to fold this different problem into 
the Y2038 document, the distinction should be made clear. These 
functions include nanosleep, setitimer, getitmer, struct itimerval, 
select, struct rusage, getrusage, struct vtimes, vtimes (and if we list 
'select', why not pselect?) Also, shouldn't rlim_t and 
sched_rr_get_interval be in the same camp as these?