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.
So awk (and other) utilities that are compiled in a conforming
programming environment will get 64-bit (or wider) time_t.
However, you can expect 32-bit time_t to survive a little longer, as
implementations that currently support both 32-bit and 64-bit
programming environments will naturally continue to support both, and
they may well decide to declare that only the 64-bit environment
conforms to POSIX rather than making time_t 64-bit in the 32-bit
environment.
On the other hand, implementations that *only* support 32-bit time_t
will have to change in order to conform.
--
Geoff Clare <
net...@gclare.org.uk>