xkcd: Y2K and 2038

[Lynn McGuire]

xkcd: Y2K and 2038
https://xkcd.com/2697/

It shouldn't cost more than a trillion dollars or two to investigate this.

Explained at:
https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038

Lynn

[Jibini Kula Tumbili Kujisalimisha]

Lynn McGuire <lynnmc...@gmail.com> wrote in
news:tkmbd3$uc0u$2...@dont-email.me:

> xkcd: Y2K and 2038
> https://xkcd.com/2697/
>
> It shouldn't cost more than a trillion dollars or two to
> investigate this.

I'll start doing so as soon as the check clears.

Or it could end up being as big a nothingburger as y2k was, because
the people who run such systems aren't idiots.

--
Terry Austin

"Terry Austin: like the polio vaccine, only with more asshole."
-- David Bilek

Jesus forgives sinners, not criminals.

[Lynn McGuire]

On 11/11/2022 5:39 PM, Jibini Kula Tumbili Kujisalimisha wrote:
> Lynn McGuire <lynnmc...@gmail.com> wrote in
> news:tkmbd3$uc0u$2...@dont-email.me:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to
>> investigate this.
>
> I'll start doing so as soon as the check clears.
>
> Or it could end up being as big a nothingburger as y2k was, because
> the people who run such systems aren't idiots.

A simple recompile with modern C compiler takes you from 2038 to 2106 if
you are using time_t. Maybe.
https://en.wikipedia.org/wiki/Year_2038_problem

Lynn

[Scott Lurndal]

Jibini Kula Tumbili Kujisalimisha <taus...@gmail.com> writes:
>Lynn McGuire <lynnmc...@gmail.com> wrote in
>news:tkmbd3$uc0u$2...@dont-email.me:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to
>> investigate this.
>
>I'll start doing so as soon as the check clears.
>
>Or it could end up being as big a nothingburger as y2k was, because
>the people who run such systems aren't idiots.

We (Burroughs) started preparing for 2000 in 1987. None of our customers
were affected by the rollover (and most customer software on those mainframes
used two-digit year fields in 1987).

And, on the vast majority of unix/linux servers/desktops currently running,

sizeof(time_t)=8 (64 bits)

Which pushes the "2038" date out to December 4th, in the year 292,277,026,596.

For the most part, a nothingburger. However, there are likely lots of
small embedded 32-bit processors in devices like routers which may exhibit
issues, if they're still running 16 years from now.

[Ninapenda Jibini]

sc...@slp53.sl.home (Scott Lurndal) wrote in
news:l9PbL.74464$1449....@fx14.iad:

> For the most part, a nothingburger. However, there are likely
> lots of small embedded 32-bit processors in devices like routers
> which may exhibit issues, if they're still running 16 years from
> now.
>

You sound just like the doom criers ("Give me money or you'll
DIE!!!") in the run up to y2k.

How many appliances with embedded processors running today do you
actually believe will still be functional in another 16 years?

https://www.wired.com/2000/01/y2k-alarmist-wha-happened/

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

[Scott Lurndal]

Ninapenda Jibini <taus...@gmail.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) wrote in
>news:l9PbL.74464$1449....@fx14.iad:
>
>> For the most part, a nothingburger. However, there are likely
>> lots of small embedded 32-bit processors in devices like routers
>> which may exhibit issues, if they're still running 16 years from
>> now.
>>
>You sound just like the doom criers ("Give me money or you'll
>DIE!!!") in the run up to y2k.

I said "if they're still running 16 years from now", which is
quite unlikely. However, cheap-ass manufacturers may continue
to use the same software in newer devices, sadly.

[Paul S Person]

So, two questions occur:

1. This appears to be a Unix problem. Apart of Unix and Linux and
friends, will anyone /else/ be affected?

2. Why go to 33 bits? If the problem is that 32 is too few, why not
just jump to 64 and save the future some problems? Is doing things in
the clearly least optimal way (you are going to end up with 40 bits
anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
tradition? Do Real Programmers always to things the Most Difficult Way
Possible?

--
"In this connexion, unquestionably the most significant
development was the disintegration, under Christian
influence, of classical conceptions of the family and
of family right."

[pyotr filipivich]

sc...@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
typed in rec.arts.sf.written the following:

It is possible. As the cliche was "back in my day" - most of the
current batch of programmers have no idea that there are COBOL
programs still running which were compiled before they were born.

The question is, how many people / organizations have a system
which has been running, is running, will be running, with little or no
reason to replace it with a New And Improved Hardware?
--
pyotr filipivich
This Week's Panel: Us & Them - Eliminating Them.
Next Month's Panel: Having eliminated the old Them(tm)
Selecting who insufficiently Woke(tm) as to serve as the new Them(tm)

[Dave Van Domelen]

Y2K was a "nothingburger" because of all the work done to stop it from
being a triple-decker shit sandwitch. If everyone had treated it like no big
deal, it would have been a very big deal.

Dave Van Domelen, really tired of the attitude people have that if a
problem is fixed, then it was never a problem in the first place.

[Scott Lurndal]

pyotr filipivich <ph...@mindspring.com> writes:
>sc...@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
>typed in rec.arts.sf.written the following:
>>Ninapenda Jibini <taus...@gmail.com> writes:
>>>sc...@slp53.sl.home (Scott Lurndal) wrote in
>>>news:l9PbL.74464$1449....@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>>You sound just like the doom criers ("Give me money or you'll
>>>DIE!!!") in the run up to y2k.
>>
>>I said "if they're still running 16 years from now", which is
>>quite unlikely. However, cheap-ass manufacturers may continue
>>to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
>current batch of programmers have no idea that there are COBOL
>programs still running which were compiled before they were born.
>
> The question is, how many people / organizations have a system
>which has been running, is running, will be running, with little or no
>reason to replace it with a New And Improved Hardware?

Most of those workloads are still running on legacy iron, and will
for the forseeable future (IBM, Unisys). Modern workloads based on
current distributed technologies (the world-wide web, for instance)
are either already 64-bit clean. The time_t issue is uniquely an
Unix issue and those, aside from the low-end consumer grade hardware mentioned
above, are largely already 64-bit clean.

The competence of programmers varies, and it is likely that there is
a fair amount of software that treats time_t as interchangable with
the C/C++ 'int' type, which is prima facia broken, but works in 32-bit
environments (and may continue to work post 2038 depending on the
context of the usage).

[Ted Nolan <tednolan>]

In article <hekvmhh5jjbjnmefu...@4ax.com>,

Paul S Person <pspe...@old.netcom.invalid> wrote:
>On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
><lynnmc...@gmail.com> wrote:
>
>>xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>>It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>>Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
>So, two questions occur:
>
>1. This appears to be a Unix problem. Apart of Unix and Linux and
>friends, will anyone /else/ be affected?
>
>2. Why go to 33 bits? If the problem is that 32 is too few, why not
>just jump to 64 and save the future some problems? Is doing things in
>the clearly least optimal way (you are going to end up with 40 bits
>anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
>tradition? Do Real Programmers always to things the Most Difficult Way
>Possible?
>

Most systems have already gone to 64 bits for time_t. The only case
I can think of for going to an unsigned 32 bit int would be if you
are targeting legacy embedded hardware of some sort and 64-bit work
is significantly slower (and/or your legacy compiler doesn't even
support 64-bit ints).
--
columbiaclosings.com
What's not in Columbia anymore..

[Lynn McGuire]

The operating systems arefixed but the customer software is not. The
software at minimum needs a recompile. But the software needs a going
through to see if it is just stuffing the time and date information into
a 32 bit signed integer.

Lynn

[Ninapenda Jibini]

sc...@slp53.sl.home (Scott Lurndal) wrote in news:cgQbL.91949
$2Rs3....@fx12.iad:

> Ninapenda Jibini <taus...@gmail.com> writes:
>>sc...@slp53.sl.home (Scott Lurndal) wrote in
>>news:l9PbL.74464$1449....@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are likely
>>> lots of small embedded 32-bit processors in devices like routers
>>> which may exhibit issues, if they're still running 16 years from
>>> now.
>>>
>>You sound just like the doom criers ("Give me money or you'll
>>DIE!!!") in the run up to y2k.
>
> I said "if they're still running 16 years from now", which is
> quite unlikely.

Unlikely enough to not be worth considering. Or mentioning.

> However, cheap-ass manufacturers may continue
> to use the same software in newer devices, sadly.
>

*Just* like Gary North.

[Lynn McGuire]

On 11/12/2022 11:07 AM, Paul S Person wrote:
> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmc...@gmail.com> wrote:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux and
> friends, will anyone /else/ be affected?
>
> 2. Why go to 33 bits? If the problem is that 32 is too few, why not
> just jump to 64 and save the future some problems? Is doing things in
> the clearly least optimal way (you are going to end up with 40 bits
> anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
> tradition? Do Real Programmers always to things the Most Difficult Way
> Possible?

1. Anyone who stuffs a time value into a 32 bit signed integer is going
to have problems at some point. Lots of mainframes did that over the years.

2. The 33 bits is joke and is difficult to implement. Randall Munroe
(the xkcd dude) is a physics dude with an incredibly popular stick
figure comic strip that runs three times a week.
https://xkcd.com/about/

I started off programming on the Univac 1108, a 36 bit machine. When we
ported to the IBM 370 in 1977?, a 32 bit machine, we had tremendous
problems with precision in our floating point. Turns out after all
these years, 32 bit still sucks.

Lynn

[Ninapenda Jibini]

dva...@eyrie.org (Dave Van Domelen) wrote in
news:tkongi$4gc$1...@hope.eyrie.org:

> Y2K was a "nothingburger" because of all the work done to
> stop it from
> being a triple-decker shit sandwitch. If everyone had treated
> it like no big deal, it would have been a very big deal.

Indeed. It's almost like critical computer systems that companies and
people depend on for Very Important Things have people whose job is
to keep an eye on things, keep things up to date, and upgrade as
needed.

>
> Dave Van Domelen, really tired of the attitude people have
> that if a
> problem is fixed, then it was never a problem in the first
> place.
>

Cheese Eating Surrender Monkey, really tired of idiots who assume
that because professionals did their job once, they can't possibly do
so again.

It's not a big deal if those professionals keep doing their jobs, and
- this is the part you're apparently too stupid to understand -
*doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.

It's *routine.*

[Ninapenda Jibini]

Paul S Person <pspe...@old.netcom.invalid> wrote in
news:hekvmhh5jjbjnmefu...@4ax.com:

> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmc...@gmail.com> wrote:
>
>>xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>>It shouldn't cost more than a trillion dollars or two to
>>investigate this.
>>
>>Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux
> and friends, will anyone /else/ be affected?
>
> 2. Why go to 33 bits? If the problem is that 32 is too few, why
> not just jump to 64 and save the future some problems? Is doing
> things in the clearly least optimal way (you are going to end up
> with 40 bits anyway, since they come in 8-bit groups called
> "bytes") a Unix/Linux tradition? Do Real Programmers always to
> things the Most Difficult Way Possible?
>

Perhaps it's comic, and 33 bits is funnier than 64, and _you missed
the joke_.

[Ninapenda Jibini]

Lynn McGuire <lynnmc...@gmail.com> wrote in

news:tkor96$177j$1...@gioia.aioe.org:

Do you anticipate a lot of problems getting that done in the next
16 years?

--
Terry Austin

Proof that Alan Baker is a liar and a fool, and even stupider than
Lynn:
https://www.cbp.gov/newsroom/stats/sw-border-migration

[Robert Carnegie]

On Saturday, 12 November 2022 at 17:07:27 UTC, Paul S Person wrote:
> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmc...@gmail.com> wrote:
>
> >xkcd: Y2K and 2038
> > https://xkcd.com/2697/
> >
> >It shouldn't cost more than a trillion dollars or two to investigate this.
> >
> >Explained at:
> > https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux and
> friends, will anyone /else/ be affected?

Apple and Microsoft use UNIX or Linux or use UNIX time.

> 2. Why go to 33 bits? If the problem is that 32 is too few, why not
> just jump to 64 and save the future some problems? Is doing things in
> the clearly least optimal way (you are going to end up with 40 bits
> anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
> tradition? Do Real Programmers always to things the Most Difficult Way
> Possible?

33 bits addresses the problem for now, and when it
consequently comes around again, people will be alive
with some memory of how it was fixed last time.
And it doesn't use an excess of storage space.

[Ted Nolan <tednolan>]

In article <e77ddac9-b70f-452d...@googlegroups.com>,

33 bits is a joke. It's a comic strip.

[Dimensional Traveler]

On 11/12/2022 9:48 AM, pyotr filipivich wrote:
> sc...@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
> typed in rec.arts.sf.written the following:
>> Ninapenda Jibini <taus...@gmail.com> writes:
>>> sc...@slp53.sl.home (Scott Lurndal) wrote in
>>> news:l9PbL.74464$1449....@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>> You sound just like the doom criers ("Give me money or you'll
>>> DIE!!!") in the run up to y2k.
>>
>> I said "if they're still running 16 years from now", which is
>> quite unlikely. However, cheap-ass manufacturers may continue
>> to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
> current batch of programmers have no idea that there are COBOL
> programs still running which were compiled before they were born.
>
> The question is, how many people / organizations have a system
> which has been running, is running, will be running, with little or no
> reason to replace it with a New And Improved Hardware?

A surprisingly large number would be my guess.

--
I've done good in this world. Now I'm tired and just want to be a cranky
dirty old man.

[Mark Jackson]

On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
> dva...@eyrie.org (Dave Van Domelen) wrote in

>> Dave Van Domelen, really tired of the attitude people have
>> that if a
>> problem is fixed, then it was never a problem in the first
>> place.
>>
> Cheese Eating Surrender Monkey, really tired of idiots who assume
> that because professionals did their job once, they can't possibly do
> so again.
>
> It's not a big deal if those professionals keep doing their jobs, and
> - this is the part you're apparently too stupid to understand -
> *doing* *their* *jobs* *isn't* *a* *big* *deal* *either*.
>
> It's *routine.*

Not a regular reader of the Risks digest, then.

--
Mark Jackson - https://mark-jackson.online/
Reasoning will never make a man correct an ill opinion, which
by reasoning he never acquired: for in the course of things,
men always grow vicious before they become unbelievers.
- Jonathan Swift

[Lynn McGuire]

Hard to tell. There is an enormous amount of custom software in companies.

Lynn

[John W Kennedy]

On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
> sc...@slp53.sl.home (Scott Lurndal) wrote in
> news:l9PbL.74464$1449....@fx14.iad:
>
>> For the most part, a nothingburger. However, there are likely
>> lots of small embedded 32-bit processors in devices like routers
>> which may exhibit issues, if they're still running 16 years from
>> now.
>>
> You sound just like the doom criers ("Give me money or you'll
> DIE!!!") in the run up to y2k.
>
> How many appliances with embedded processors running today do you
> actually believe will still be functional in another 16 years?
>
> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>

Do not misunderstand. The Y2K problem was very real, and started causing
serious damage at least as early as August 16, 1972 (9999 days before
Y2K), when tapes on IBM mainframes that were supposed to be marked
“retain forever” started to be marked "ready for recycling” instead.

(It was also about that time that our operating system—to be fair to
IBM, it was a beta—started crashing every day at exactly 7:00PM EST. It
turned out to be caused by a zero divide in the rollover-GMT code—7:00PM
EST is midnight, GMT. And why the zero divide? Ultimately, because one
IBM coder was aware that, in the Gregorian Calendar, AD 1900 had skipped
leap year, while another coder was blissfully unaware of it.)

--
John W. Kennedy
Algernon Burbage, Lord Roderick, Father Martin, Bishop Baldwin,
King Pellinore, Captain Bailey, Merlin -- A Kingdom for a Stage!

[John W Kennedy]

On 11/12/22 12:07 PM, Paul S Person wrote:
> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
> <lynnmc...@gmail.com> wrote:
>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to investigate this.
>>
>> Explained at:
>> https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>
> So, two questions occur:
>
> 1. This appears to be a Unix problem. Apart of Unix and Linux and
> friends, will anyone /else/ be affected?

Don’t forget that macOS, iOS, iPadOS, tvOS, audioOS, and watchOS are all
built on Unix. However, programs for those operating systems are
normally coded using the Foundation library, and are all 64-bit-only by
now, so they shouldn’t have too much trouble.

> 2. Why go to 33 bits? If the problem is that 32 is too few, why not
> just jump to 64 and save the future some problems? Is doing things in
> the clearly least optimal way (you are going to end up with 40 bits
> anyway, since they come in 8-bit groups called "bytes") a Unix/Linux
> tradition? Do Real Programmers always to things the Most Difficult Way
> Possible?

I’m fairly certain 33 bits is a joke.

[John W Kennedy]

On 11/12/22 12:48 PM, pyotr filipivich wrote:
> sc...@slp53.sl.home (Scott Lurndal) on Sat, 12 Nov 2022 16:57:44 GMT
> typed in rec.arts.sf.written the following:
>> Ninapenda Jibini <taus...@gmail.com> writes:
>>> sc...@slp53.sl.home (Scott Lurndal) wrote in
>>> news:l9PbL.74464$1449....@fx14.iad:
>>>
>>>> For the most part, a nothingburger. However, there are likely
>>>> lots of small embedded 32-bit processors in devices like routers
>>>> which may exhibit issues, if they're still running 16 years from
>>>> now.
>>>>
>>> You sound just like the doom criers ("Give me money or you'll
>>> DIE!!!") in the run up to y2k.
>>
>> I said "if they're still running 16 years from now", which is
>> quite unlikely. However, cheap-ass manufacturers may continue
>> to use the same software in newer devices, sadly.
>
> It is possible. As the cliche was "back in my day" - most of the
> current batch of programmers have no idea that there are COBOL
> programs still running which were compiled before they were born.

Some say it was only thanks to Y2K that emulated 1401s finally vanished.

> The question is, how many people / organizations have a system
> which has been running, is running, will be running, with little or no
> reason to replace it with a New And Improved Hardware?

--

[Robert Carnegie]

Also that, yes. Although historically, bits didn't have
to come in eights... or to be bits.

> It's a comic strip.

Also that, yes.

[John W Kennedy]

Lots of business-related stuff on the web is based on code that
screen-scrapes virtual 3270s running on ancient COBOL programs, or at
least was until recently.

> The time_t issue is uniquely an
> Unix issue and those, aside from the low-end consumer grade hardware mentioned
> above, are largely already 64-bit clean.
>
> The competence of programmers varies, and it is likely that there is
> a fair amount of software that treats time_t as interchangable with
> the C/C++ 'int' type, which is prima facia broken, but works in 32-bit
> environments (and may continue to work post 2038 depending on the
> context of the usage).

[Ninapenda Jibini]

Mark Jackson <mjac...@alumni.caltech.edu> wrote in
news:jtaee3...@mid.individual.net:

> On 11/12/2022 2:35 PM, Ninapenda Jibini wrote:
>> dva...@eyrie.org (Dave Van Domelen) wrote in
>
>>> Dave Van Domelen, really tired of the attitude people have
>>> that if a
>>> problem is fixed, then it was never a problem in the first
>>> place.
>>>
>> Cheese Eating Surrender Monkey, really tired of idiots who
>> assume that because professionals did their job once, they
>> can't possibly do so again.
>>
>> It's not a big deal if those professionals keep doing their
>> jobs, and - this is the part you're apparently too stupid to
>> understand - *doing* *their* *jobs* *isn't* *a* *big* *deal*
>> *either*.
>>
>> It's *routine.*
>
> Not a regular reader of the Risks digest, then.
>

I was for a while. Yes, stupid people do stupid things.

But the world didn't end at midnight, December 31, 1999, despite the
predictions of idiots like you.

And it won't in 2038, either, despite predictions by idiots like you.

[Ninapenda Jibini]

Lynn McGuire <lynnmc...@gmail.com> wrote in

news:tkp0co$1bor$1...@gioia.aioe.org:

But then, given your preference for post apocalyptic revcenge
fantasies, you might be a tad biased.

[Ninapenda Jibini]

John W Kennedy <john.w....@gmail.com> wrote in
news:o0idnQslu6gLie3-...@giganews.com:

> On 11/12/22 11:32 AM, Ninapenda Jibini wrote:
>> sc...@slp53.sl.home (Scott Lurndal) wrote in
>> news:l9PbL.74464$1449....@fx14.iad:
>>
>>> For the most part, a nothingburger. However, there are
>>> likely lots of small embedded 32-bit processors in devices
>>> like routers which may exhibit issues, if they're still
>>> running 16 years from now.
>>>
>> You sound just like the doom criers ("Give me money or you'll
>> DIE!!!") in the run up to y2k.
>>
>> How many appliances with embedded processors running today do
>> you actually believe will still be functional in another 16
>> years?
>>
>> https://www.wired.com/2000/01/y2k-alarmist-wha-happened/
>>
>
> Do not misunderstand. The Y2K problem was very real, and started
> causing serious damage at least as early as August 16, 1972
> (9999 days before Y2K), when tapes on IBM mainframes that were
> supposed to be marked “retain forever” started to be marked
> "ready for recycling” instead.

Serious, perhaps, but not especially wide spread.

>
> (It was also about that time that our operating system—to be
> fair to IBM, it was a beta—started crashing every day at
> exactly 7:00PM EST. It turned out to be caused by a zero divide
> in the rollover-GMT code—7:00PM EST is midnight, GMT. And why
> the zero divide? Ultimately, because one IBM coder was aware
> that, in the Gregorian Calendar, AD 1900 had skipped leap year,
> while another coder was blissfully unaware of it.)
>

And did hellfire rain down from the heavens, with cats and dogs
living together, heralding the end of human civilization? No.
Nobody kicked your dog, either. Professionals fixed it, and life
went on.

And we know 2038 is coming. Decades in advance.

[Your Name]

On 11/11/2022 5:39 PM, Jibini Kula Tumbili Kujisalimisha wrote:
> Lynn McGuire <lynnmc...@gmail.com> wrote in

> news:tkmbd3$uc0u$2...@dont-email.me:
>>
>> xkcd: Y2K and 2038
>> https://xkcd.com/2697/
>>
>> It shouldn't cost more than a trillion dollars or two to
>> investigate this.
>
> I'll start doing so as soon as the check clears.
>
> Or it could end up being as big a nothingburger as y2k was, because
> the people who run such systems aren't idiots.

Y2K was massively over-hyped - largely by the media, as usual. There
was never going to be huge issues with with things like traffic lights
and elevators suddenly not working. There were also a lot of tech
people who jumped on this scaremongering bandwagon to greedily increase
their own pay-packets.

2038, and whatever other year turnovers they discover, will be no different.

[rksh...@rosettacondot.com]

Robert Carnegie <rja.ca...@excite.com> wrote:
> On Saturday, 12 November 2022 at 17:07:27 UTC, Paul S Person wrote:
>> On Fri, 11 Nov 2022 14:30:25 -0600, Lynn McGuire
>> <lynnmc...@gmail.com> wrote:
>>
>> >xkcd: Y2K and 2038
>> > https://xkcd.com/2697/
>> >
>> >It shouldn't cost more than a trillion dollars or two to investigate this.
>> >
>> >Explained at:
>> > https://www.explainxkcd.com/wiki/index.php/2697:_Y2K_and_2038
>> So, two questions occur:
>>
>> 1. This appears to be a Unix problem. Apart of Unix and Linux and
>> friends, will anyone /else/ be affected?
>
> Apple and Microsoft use UNIX or Linux or use UNIX time.

IoT devices...something like 70-80% of them (choose your estimates) are Linux
underneath. There's also a lot of Linux code reuse in non-Linux devices.
Linux and the various BSD releases have used 64-bit time values on 64-bit
architectures for roughly the last 10 years but it's only within the last
two that Linux started supporting 64-bit time on 32-bit systems. The hope is
that manufacturers will pick that up within the next few years. If so then
the main concern will be old devices that never received an update...hopefully
not too many of them left after 10-15 years.

Robert
--
Robert K. Shull Email: rkshull at rosettacon dot com

[rksh...@rosettacondot.com]

Well, I'll admit that I got a very nice boost for the holiday by volunteering
(at 8x times my normal pay) to sit at work rather than stay home with the
family on New Year's Eve.
There were a LOT of function-breaking bugs fixed in significant bits of
infrastructure leading up to Y2K. Other than generating a whole lot of sales
to preppers, the hype did one really important thing...it got the bean
counters listening to what the the engineers had been saying for years.
Which was, essentially, that the bean counters were going to regret their
inaction when the lawsuits started rolling in. Even if the failures weren't
of the "All die. Oh the embarrassment." type, customers tend to frown on things
like, for example, discovering that the service they were charging by the
minute for stopped recording usage on January 1st.
It was never a matter of not knowing that there was a problem, it was a
matter of prioritizing remediation over new features and other bugs.
Even with the effort put in, we still saw plenty of unpatched (mostly
cosmetic) issues. The most common was probably seeing dates displayed as
"1-1-19100".

[pete...@gmail.com]

The first step was always to set up un isolated environment, roll the clocks
forward to Dec 31, 1999, and run simulated data to see how the system
behaved crossing over midnight, and a normal work cycle (say, a week)
forward.

Pt