Re: Y2K38 bug (January 19, 2038)

Liste des GroupesRevenir à cl awk 
Sujet : Re: Y2K38 bug (January 19, 2038)
De : gazelle (at) *nospam* shell.xmission.com (Kenny McCormack) (gazelle@shell.xmission.com (Kenny McCormack))
Groupes : comp.lang.awk
Date : 08. Mar 2024, 21:11:45
Autres entêtes
Organisation : The official candy of the new Millennium
Message-ID : <usfre1$293dh$1@news.xmission.com>
References : 1
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.

Date Sujet#  Auteur
8 Mar 24 * Re: Y2K38 bug (January 19, 2038)5gazelle@shell.xmission.com (Kenny McCormack)
11 Mar 24 `* Re: Y2K38 bug (January 19, 2038)4Mr. Man-wai Chang
11 Mar 24  +* Re: Y2K38 bug (January 19, 2038)2Ben Bacarisse
11 Mar 24  i`- Re: Y2K38 bug (January 19, 2038)1Mr. Man-wai Chang
11 Mar 24  `- Re: Y2K38 bug (January 19, 2038)1Keith Thompson

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal