Year 2030 problem

[muta...@gmail.com]

I'm thinking of replacing the Year 2038 problem
with a Year 2030/2040/2050/etc recurring problem.

Basically if the current year is 2030-2040, then
time_t is represented as number of seconds since
1980 instead of 1970. Repeat every 10 years.

This means if you do a "dir" on PDOS/386 (but not
PDOS/Vaporware-x64) you won't be able to see both
1970s files and 2030s files, since internally it goes
via time_t.

Not sure if I should make it 2038-01-01 instead of
2030-01-01. The latter will be easier to keep track
of for humans.

My files date from about 1988. I bought my PC XT
in 1987 or 1988, can't remember. Commodore PC 5
with 20 MB hard disk and monochrome text monitor.

BFN. Paul.



(oldest file in my Sidekick directory)

C:\extra\ddrive\skstuff>dir pizza
Volume in drive C is OS
Volume Serial Number is 500F-DBAC

Directory of C:\extra\ddrive\skstuff

1988-08-07 23:36 183 pizza
1 File(s) 183 bytes
0 Dir(s) 70,108,205,056 bytes free

C:\extra\ddrive\skstuff>type pizza
Capitano's: Medium Mexican $7.00

Pizza Pizzaz: Medium Mushroom $10.40

Domino's Medium Mexican $11.50
Medium Vegie $11.50

Pizza Hut Medium Mushroom $10.50

[Rod Pemberton]

On Sat, 19 Jun 2021 13:15:11 -0700 (PDT)
"muta...@gmail.com" <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?

[muta...@gmail.com]

On Sunday, June 20, 2021 at 1:57:01 PM UTC+10, Rod Pemberton 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?

I'm (proposing) doing both, automatically, starting in
2030, with an adjustment every 10 years after that,
for eternity.

> 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.

I already know what the C standard says, and I've
already got a conforming implementation. I chose
to use 1970 the same as is normally done (but
not mandated by C90). You can see "1970" here:

https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/time.c

I was just planning on dynamically shifting that 1970.

BFN. Paul.

[Rod Pemberton]

On Sat, 19 Jun 2021 21:06:16 -0700 (PDT)
"muta...@gmail.com" <muta...@gmail.com> wrote:

> On Sunday, June 20, 2021 at 1:57:01 PM UTC+10, Rod Pemberton 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?
>
> I'm (proposing) doing both, automatically, starting in
> 2030, with an adjustment every 10 years after that,
> for eternity.
>

> [...]

>
> I was just planning on dynamically shifting that 1970.
>

It'd work on the software side, but you'd have the
side effect of dates and times being off every decade.
Why wouldn't you use a larger period like the nearly
seventy years from 1970 to 2038?

I don't remember enough about the CMOS RTC to know
if it's an issue.

[muta...@gmail.com]

On Sunday, June 20, 2021 at 2:24:48 PM UTC+10, Rod Pemberton wrote:

> > I was just planning on dynamically shifting that 1970.
> >
> It'd work on the software side, but you'd have the
> side effect of dates and times being off every decade.

time_t is only supposed to be for internal use. You can't
rely on it being anything in particular.

> Why wouldn't you use a larger period like the nearly
> seventy years from 1970 to 2038?

That's what I was originally thinking of doing, but I
"realized" that that would mean when I did a "dir"
all of my data would appear to be between 2038
and 2100+.

> I don't remember enough about the CMOS RTC to know
> if it's an issue.

It doesn't matter if the RTC covers the year 0000 to 9999.
I have a 32-bit limit, so I need a scheme to work within that.

BFN. Paul.

[wolfgang kern]

On 20.06.2021 07:26, Rod Pemberton wrote:

[...Year 2038 problem]

>>>> I was just planning on dynamically shifting that 1970.

I never had this problem because my file-system stores date and
time in a less restricted format:
YYYY,MM,DD,Hr,Min,Sec,Milli-Second [2021_06_18_11:30:59.999]
(4 + 5*2 + 3 BCD nibbles +4 bits for ownership flags)
9 bytes altogether, RTC talks BCD, easy readable in a hex-dump
and year 0000 to 9999 could be enough for a while :)

> It'd work on the software side, but you'd have the
> side effect of dates and times being off every decade.
> Why wouldn't you use a larger period like the nearly
> seventy years from 1970 to 2038?

> I don't remember enough about the CMOS RTC to know
> if it's an issue.

In the old days there was only one CMOS byte used, written by
BIOS or the OS. Newer south-bridge stuff can do lap years and
daylight-saving and even lap seconds by itself.
__
wolfgang

[JJ]

On Sat, 19 Jun 2021 21:42:51 -0700 (PDT), muta...@gmail.com wrote:
>
> It doesn't matter if the RTC covers the year 0000 to 9999.
> I have a 32-bit limit, so I need a scheme to work within that.
>
> BFN. Paul.

Actually, the limit is 31-bit. So, why not use the entire 32-bit? i.e. an
unsigned `time_t`. That'll give you another 68 years, before actually
hitting the 32-bit limit. I'm pretty sure most people here would have been
in their utopia by then.

If that isn't enough, then make a completely new specification. No point of
using a specification which needs periodical fixing.

[muta...@gmail.com]

On Monday, June 21, 2021 at 2:26:13 AM UTC+10, JJ wrote:

> > It doesn't matter if the RTC covers the year 0000 to 9999.
> > I have a 32-bit limit, so I need a scheme to work within that.

> Actually, the limit is 31-bit. So, why not use the entire 32-bit? i.e. an
> unsigned `time_t`. That'll give you another 68 years, before actually
> hitting the 32-bit limit. I'm pretty sure most people here would have been
> in their utopia by then.

Thankyou sir! That saved me a lot of grief. Actually, I'm
already using an unsigned long, but I thought the limit
was 2038. I checked again and you are right, I'm set
until 2106, and if I'm not dead by then, I'll simply suicide
instead of moving from 32-bit.

It's funny that I just read something recently that said
we all need to upgrade to 64-bit to avoid the 2038
problem.

> If that isn't enough, then make a completely new specification. No point of
> using a specification which needs periodical fixing.

My proposal wasn't to periodically fix it. Just the internal time_t
meaning would change every 10 years, automatically.

BFN. Paul.

[muta...@gmail.com]

On Monday, June 21, 2021 at 8:10:17 AM UTC+10, muta...@gmail.com wrote:

> was 2038. I checked again and you are right, I'm set
> until 2106, and if I'm not dead by then, I'll simply suicide
> instead of moving from 32-bit.

Actually, how about combining the two and creating
a Year 2100 problem? That way I get to live for an
extra 10 years before losing my 1980s timestamps,
and people born in say 2080 don't need to recompile
my binaries. They will still be able to do a "dir" and
see sensible dates. In the year 2120 they would only
be able to see sensible dates for files starting from
1990, but that's probably sufficient.

BFN. Paul.