Y2K38 bug (January 19, 2038)

[J Naman]

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?
I 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.

[Geoff Clare]

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>

[Russell Marks]

J Naman <jna...@gmail.com> wrote:

> Is there any plan or schedule for POSIX to replace the Unix 32-bit

> time [...] I am really asking if GNU awk or other awks expect to
> upgrade before or after the next revision of POSIX in 2026? [...]

> I keep running into Y2K38 issues with some US government data.

If you use GNU awk on a *recent* Linux or *BSD, it should work
already. "gawk 'BEGIN{print strftime("%Y",1e10)}'" on Debian Bookworm
gives 2286, for example.

-Rus.