Second draft of the Y2038 design document

[Paul Eggert]

Albert ARIBAUD wrote:
> What about using GLIBC used over a current 64-bit kernel version, which
> does not have proper Y2038 support, which makes GLIBC unable to provide
> correct time-of-day past Y2038?

We're saying "don't do that".

> Should this GLIBC/kernel version combination be considered forbidden,
> IOW, are we saying a Y2038-proof GLIBC should only be used with a
> Y2038-proof kernel?

No, we're saying that if your kernel has a Y2038 bug, the resulting system has a 
Y2038 bug. That doesn't mean you can't run a Y2038-safe glibc atop the buggy kernel.

By the way, a common problem with 64-bit kernels is not Y2038, it's something 
trickier, e.g., arbitrary limits at 2**63 / 1000000 because someone naively used 
a 64-bit microsecond counter. These limits are often well past 2038, but they 
don't have to be.  Are you worried about all arbitrary time limits before 2**63, 
or just time limits that show up by 2038?  For example, how about the time limit 
2**32 (in the year 2106)?

PS.  Did I mention the amusing limit hardcoded into zic?  It refuses to accept 
time stamps before the Big Bang....