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.

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 <netnews@gclare.org.uk>

J Naman <jnaman2@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.

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 */

In article <b2321bbf-e9a1-40d5-9261-db53a98a8dadn@googlegroups.com>,
J Naman <jnaman2@gmail.com> 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?
>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.

This is a non-issue in GAWK. Note that AWK in general does not have an
integer type. It just has a "number" type - and that type is a C double.

Observe:

% gawk 'BEGIN { print strftime("%c",1e12)}'
Thu Sep 26 19:46:40 33658
%

So, I think we're good.

--
It's possible that leasing office space to a Starbucks is a greater liability
in today's GOP than is hitting your mother on the head with a hammer.

On 9/3/2024 4:11 am, Kenny McCormack wrote:
>
> This is a non-issue in GAWK. Note that AWK in general does not have an
> integer type. It just has a "number" type - and that type is a C double.
>
> Observe:
>
> % gawk 'BEGIN { print strftime("%c",1e12)}'
> Thu Sep 26 19:46:40 33658
> %
>
> So, I think we're good.

Well, you can always outsource the job using system()! :)

Year 2038 problem is not just a software issue. You also need 64-bit CPU
to compute dates. Awk is just a tool that makes use of operating systems.

Year 2038 problem - Wikipedia
<https://en.wikipedia.org/wiki/Year_2038_problem>

Keith Thompson wrote:

> Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
>>
>> 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?

https://www.opengroup.org/austin/login.html

Access is restricted - you need to have an account on www.opengroup.org
and be subscribed to the austin-group-l mailing list. (At least, I
think that's all you need, but ICBW.)

--
Geoff Clare <netnews@gclare.org.uk>

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> Year 2038 problem is not just a software issue. You also need 64-bit CPU to
> compute dates.

Since software can emulate 64-bt computations, it /is/ just a software
issue.

--
Ben.

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:
> On 9/3/2024 4:11 am, Kenny McCormack wrote:
>> This is a non-issue in GAWK. Note that AWK in general does not have
>> an
>> integer type. It just has a "number" type - and that type is a C double.
>> Observe:
>> % gawk 'BEGIN { print strftime("%c",1e12)}'
>> Thu Sep 26 19:46:40 33658
>> %
>> So, I think we're good.
>
> Well, you can always outsource the job using system()! :)
>
> Year 2038 problem is not just a software issue. You also need 64-bit
> CPU to compute dates. Awk is just a tool that makes use of operating
> systems.
>
> Year 2038 problem - Wikipedia
> <https://en.wikipedia.org/wiki/Year_2038_problem>

It is just a software issue. Awk is implemented in C. ISO C has
required 64-bit integer support since 1999.

C specifies the time() function, and does not place restrictions on
time_t or specify just how it represents times. POSIX currently does
not require 64-bit time_t, but apparently will in its next edition.

--
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 */

On 11/3/2024 10:27 pm, Ben Bacarisse wrote:
>
> Since software can emulate 64-bt computations, it /is/ just a software
> issue.

This is the part I don't quite understand. I remember the Y2K problem,
but I was dealing with Foxpro for DOS not C.

On 9/3/2024 3:51 am, Keith Thompson wrote:
>
> 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.

Could we roll our own signed time_t? :)

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:
> On 9/3/2024 3:51 am, Keith Thompson wrote:
>> 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.
>
> Could we roll our own signed time_t? :)

I see the smiley, but I don't get the joke.

If you're creating your own implementation, you can do anything you
like. If not, and you're using an implementation that makes time_t an
unsigned type, there's not much you can do to treat it as signed. For
example, localtime() would presumably treat a time_t value of -2 as a
very large unsigned value.

I don't know of any implementations that make time_t an unsigned type.

--
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 */

On Tue, 12 Mar 2024 01:43:59 +0800, "Mr. Man-wai Chang"
<toylet.toylet@gmail.com> wrote:

>On 11/3/2024 10:27 pm, Ben Bacarisse wrote:
>>
>> Since software can emulate 64-bt computations, it /is/ just a software
>> issue.
>
> This is the part I don't quite understand.

Even a 4-bit processor can handle 64-bit integers, signed or
unsigned, just not with a single instruction.
It is just a lot of code, handling 4 bits at a time, so it will
not be fast.
--
Kees Nuyt

Keith Thompson wrote:

> "Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:
>> On 9/3/2024 3:51 am, Keith Thompson wrote:
>>> 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.
>>
>> Could we roll our own signed time_t? :)
>
> I see the smiley, but I don't get the joke.
>
> If you're creating your own implementation, you can do anything you
> like. If not, and you're using an implementation that makes time_t an
> unsigned type, there's not much you can do to treat it as signed. For
> example, localtime() would presumably treat a time_t value of -2 as a
> very large unsigned value.
>
> I don't know of any implementations that make time_t an unsigned type.

QNX is one.

See www.qnx.net/developers/docs/6.4.0/neutrino/sys_arch/kernel.html
which says:

Valid dates on a QNX Neutrino system range from January 1970 to at
least 2038. The time_t data type is an unsigned 32-bit number, which
extends this range for many applications through 2106.

Also, having signed time_t doesn't necessarily mean that dates before
Jan 1970 are supported. I seem to recall that MS Windows has signed
time_t but does not support negative values.

--
Geoff Clare <netnews@gclare.org.uk>

On 2024-03-12, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:

> Also, having signed time_t doesn't necessarily mean that dates before
> Jan 1970 are supported.

mktime(3) is documented to return (time_t)-1 in case of error, which
bodes ill for Dec 31, 1969, 23:59:59 UTC.

--
Christian "naddy" Weisgerber naddy@mips.inka.de

Christian Weisgerber <naddy@mips.inka.de> writes:
> On 2024-03-12, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:
>> Also, having signed time_t doesn't necessarily mean that dates before
>> Jan 1970 are supported.
>
> mktime(3) is documented to return (time_t)-1 in case of error, which
> bodes ill for Dec 31, 1969, 23:59:59 UTC.

It can still return a correct value of -1. It does make it difficult
for the caller to determine whether a -1 return value denotes an error
or not.

--
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 */

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
> Keith Thompson wrote:
>> "Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:
>>> On 9/3/2024 3:51 am, Keith Thompson wrote:
>>>> 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.
>>>
>>> Could we roll our own signed time_t? :)
>>
>> I see the smiley, but I don't get the joke.
>>
>> If you're creating your own implementation, you can do anything you
>> like. If not, and you're using an implementation that makes time_t an
>> unsigned type, there's not much you can do to treat it as signed. For
>> example, localtime() would presumably treat a time_t value of -2 as a
>> very large unsigned value.
>>
>> I don't know of any implementations that make time_t an unsigned type.
>
> QNX is one.
>
> See www.qnx.net/developers/docs/6.4.0/neutrino/sys_arch/kernel.html
> which says:
>
> Valid dates on a QNX Neutrino system range from January 1970 to at
> least 2038. The time_t data type is an unsigned 32-bit number, which
> extends this range for many applications through 2106.
>
> Also, having signed time_t doesn't necessarily mean that dates before
> Jan 1970 are supported. I seem to recall that MS Windows has signed
> time_t but does not support negative values.

Sadly, you're right.

https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/mktime-mktime32-mktime64?view=msvc-170

_mktime32 returns the specified calendar time encoded as a value of
type time_t. If timeptr references a date before midnight, January
1, 1970, or if the calendar time can't be represented, _mktime32
returns -1 cast to type time_t.

I've worked on Windows code that had to deal with patients' birth dates
to determine their current age. I don't recall the exact details, but I
had to apply a 400-year offset to the birth date and current time to get
correct results for patients born before 1970. (The Gregorian calendar
repeats after 400 years.) We had 64-bit signed time_t, so it wasn't due
to this specific problem; with 32-bit time_t the 400-year offset
wouldn't have been possible.
--
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 */

Keith Thompson wrote:

> Christian Weisgerber <naddy@mips.inka.de> writes:
>> On 2024-03-12, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:
>>> Also, having signed time_t doesn't necessarily mean that dates before
>>> Jan 1970 are supported.
>>
>> mktime(3) is documented to return (time_t)-1 in case of error, which
>> bodes ill for Dec 31, 1969, 23:59:59 UTC.
>
> It can still return a correct value of -1. It does make it difficult
> for the caller to determine whether a -1 return value denotes an error
> or not.

C23 has introduced a way to distinguish the cases. It says:

[on error] the function returns the value (time_t)(-1) and does
not change the value of the tm_wday component of the structure.

This will also be in the forthcoming POSIX.1 revision, which adds
this advice:

Since (time_t)−1 is a valid return value for a successful call to
mktime(), an application wishing to check for error situations
should set tm_wday to a value less than 0 or greater than 6 before
calling mktime(). On return, if tm_wday has not changed an error
has occurred.

--
Geoff Clare <netnews@gclare.org.uk>

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
> Keith Thompson wrote:
>> Christian Weisgerber <naddy@mips.inka.de> writes:
>>> On 2024-03-12, Geoff Clare <geoff@clare.See-My-Signature.invalid> wrote:
>>>> Also, having signed time_t doesn't necessarily mean that dates before
>>>> Jan 1970 are supported.
>>>
>>> mktime(3) is documented to return (time_t)-1 in case of error, which
>>> bodes ill for Dec 31, 1969, 23:59:59 UTC.
>>
>> It can still return a correct value of -1. It does make it difficult
>> for the caller to determine whether a -1 return value denotes an error
>> or not.
>
> C23 has introduced a way to distinguish the cases. It says:
>
> [on error] the function returns the value (time_t)(-1) and does
> not change the value of the tm_wday component of the structure.
>
> This will also be in the forthcoming POSIX.1 revision, which adds
> this advice:
>
> Since (time_t)−1 is a valid return value for a successful call to
> mktime(), an application wishing to check for error situations
> should set tm_wday to a value less than 0 or greater than 6 before
> calling mktime(). On return, if tm_wday has not changed an error
> has occurred.

That's likely to be the behavior for older implementations. C11 isn't
quite as explicit, but it does say:

On successful completion, the values of the tm_wday and tm_yday
components of the structure are set appropriately, and the other
components are set to represent the specified calendar time, but
with their values forced to the ranges indicated above; the final
value of tm_mday is not set until tm_mon and tm_year are determined.

I think it's reasonable to assume that tm_wday and tm_yday are not
modified unless the function is successful.

--
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 */