Sujet : Re: Y2K38 bug (January 19, 2038)
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.awkDate : 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.comWorking, but not speaking, for Medtronicvoid Void(void) { Void(); } /* The recursive call of the void */