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.
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.
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 <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?
Year 2038 problem is not just a software issue. You also need 64-bit CPU to compute dates.
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.
"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.
Also, having signed time_t doesn't necessarily mean that dates before
Jan 1970 are supported.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 307 |
Nodes: | 16 (2 / 14) |
Uptime: | 99:15:45 |
Calls: | 6,850 |
Calls today: | 1 |
Files: | 12,354 |
Messages: | 5,415,223 |