Re: First draft of the Y2038 design document

[Rich Felker <dalias at libc dot org>]

On Mon, Oct 26, 2015 at 08:22:45PM -0700, Paul Eggert wrote:
> Albert ARIBAUD wrote:
> 
> >Y2038 proofness means that application calls to glibc-provided
> >function should never return wrong results when times beyond
> >2038-01-19 03:14:07 UTC are involved.
> 
> This isn't quite right for two reasons. First, if leap seconds are
> in use the broken-down UTC cutoff time is slightly different.

The relationship between time_t and broken down struct tm is strictly
specified and does not admit leap seconds.

> Second, results should also work for time_t values before - 2**31,
> as well as for time_t values after 2**31 - 1. I suggest rewording

Agreed.

> this to talk about time_t values outside the usual signed 32-bit
> range. Similarly for the other references to absolute time stamps;
> if you're going to use examples like 2038-01-19 03:14:07 UTC,
> specify that the examples assume no leap seconds.
> 
> I agree with Joseph, by the way; there's no need for _TIME64_SOURCE,
> and that _TIME_BITS=64 should suffice.

I thought _TIME64_SOURCE was to get additional interfaces with 64
suffixed onto their names, without changing the type of time_t, for
applications/libraries which need to interface with both. Personally I
would rather NOT have this functionality, because my experience from
the off_t fiasco was that lots of applications erroneously started
using the 64-suffixed functions/types rather than defining
_FILE_OFFSET_BITS=64, resulting in messy, non-portable,
non-standards-conforming code that took a long time to fix. But I
suspect lots of people want it.

Perhaps we can find some good way to convey to users that it's
undesirable to do this? For example, perhaps have a #warning if
_TIME64_SOURCE is defined but _TIME_BITS is not explicitly defined by
the application?

> >32-bit time functions will not be modified
> 
> The interface won't be modified, but it's OK if the implementation
> is changed. For example, it should be OK to change the 32-bit
> implementation of clock_gettime to be a wrapper around a 64-bit
> implementation.

Agreed. Making this explicit would be fine.

Rich