This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Second draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Mon, 21 Mar 2016 14:07:13 +0100
- Subject: Re: Second draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160128204114 dot 6c7dbbf7 dot albert dot aribaud at 3adev dot fr> <56AA8465 dot 5040803 at cs dot ucla dot edu> <20160321131520 dot 6c27251e dot albert dot aribaud at 3adev dot fr>
On Monday 21 March 2016 13:15:20 Albert ARIBAUD wrote:
> > I don't see why functions like 'time' and 'gettimeofday' should be
> > allowed to misbehave on 64-bit hosts after 2038. They should just work.
> > Glibc should not worry about 64-bit kernels without 64-bit time support.
> > Any such kernels should just get fixed before 2038 rolls around.
>
> 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?
Which OS are you thinking of?
I don't think regarding Linux, we ever had any 64-bit kernel that did not
support 64-bit time_t correctly, aside from file system time stamps that
are depending on the file system implementation (e.g. ext4 until recently
was broken)
Arnd