Re: Y2K38 bug (January 19, 2038)

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:

J Naman wrote:

Is there any plan or schedule for POSIX to replace the Unix 32-bit
time by a 64-bit time format to avoid the Y2K38 bug ( January 19,
2038, at 03:14:07 UTC.)? I am really asking if GNU awk or other awks
expect to upgrade before or after the next revision of POSIX in 2026?
Is there any certainty that POSIX WILL revise time in 2026? keep
running into Y2K38 issues with some US government data. mktime() is
no big deal to handle at the user level, but strftime() IS a (the)
real problem.

>
The current draft of the next POSIX revision has this in the
description of the <sys/types.h> header:
>
    time_t shall be an integer type with a width (see <stdint.h>) of
    at least 64 bits.
>
The revision is expected to be approved next year.

[...]
Do you have a link to that draft?
Current POSIX says that time_t is an integer type, and time() returns
the number of seconds since the Epoch, 1970-01-01 00:00:00 UTC.  All
this is more stringent than the ISO C requirements.
So a POSIX-conforming implementation can already use a 64-bit time_t,
and many do so.  What's apparently changing in the next revision is that
time_t is *required* to be at least 64 bits.
I'm a little disappointed that POSIX doesn't require time_t to be
signed.  64 bits is enough to represent a range of about 584 billion
years.  An unsigned time_t makes it impossible to represent times before
1970.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */