Re: Y2K38 bug (January 19, 2038)

Liste des GroupesRevenir à cl awk 
Sujet : Re: Y2K38 bug (January 19, 2038)
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.awk
Date : 11. Mar 2024, 16:14:40
Autres entêtes
Organisation : None to speak of
Message-ID : <87il1sztpb.fsf@nosuchdomain.example.com>
References : 1 2 3
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
"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 */

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