From: noemail@basdxcqvbe.com
On Sat, 19 Jun 2021 13:15:11 -0700 (PDT)
"muta...@gmail.com" wrote:
> I'm thinking of replacing the Year 2038 problem
> with a Year 2030/2040/2050/etc recurring problem.
>
Did you drop the eight (8) from 2038 (thirty-eight)
for a zero (0) in 2030/2040/2050 above? Was that
an intentional change or just a mistake? I.e., are
you changing the issue from 2038 (thirty-eight)
to 2030 (thirty) and also shifting the Epoch from
1970 to 1980? Or, are you just shifting the Epoch?
The "Year 2038" problem - according to Wikipedia -
affects computing systems whose starting Epoch is
1 January 1970. The Epoch of Unix like systems
is 1 January 1970. The Epoch of an x86 BIOS is
1 January 1980. So, I'd think that you'd have a
"Year 2048" (fourty-eight) problem instead of
"Year 2038" (thirty-eight).
https://en.wikipedia.org/wiki/Year_2038_problem
https://en.wikipedia.org/wiki/Epoch_(computing)
Although the Wikipedia Epoch page says C uses
an Epoch of 1 January 1970, I find that to be
rather doubtful, offhand. I see no mention of
that in Harbison & Steele, which said the "past
date" (Epoch) was arbitrary, but commonly set to
1 January 1970. But, I also didn't check the
C specifications for confirmation (too tedious).
So, I doubt that the C specification authors
would chose a hard coded the Epoch date to
1 January 1970, and suspect they preferred to
use the local system's Epoch instead.
Of course, you can always search the C
specifications for 1970 or 1980 perhaps in
conjunction with January in you wish to
determine the truth for yourself, as I've
gotten tired of looking up stuff in the C
specifications for other people, which they
could've found themselves, and which usually
confirms exactly what I stated.
--
What is hidden in the ground, when found, is hidden there again?
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
