Y2K22 Bug: Microsoft Working to Fix Email Glitch

[jtbell]

TL;DR

Microsoft Exchange servers stopped processing e-mail at midnight on New Year's Eve.

Remember the Y2K bug, 22 years ago? Now we have the Y2K22 bug. Microsoft Exchange servers overflowed a 32-bit integer at the beginning of the new year, causing them to stop processing e-mail.

https://www.dailymail.co.uk/news/ar...oft-working-clock-fix-Y2K22-email-glitch.html

 

[anorlunda]

There seems to be no end to the number of times people can screw up managing dates. Perhaps that's the real answer, date bugs are perpetual.

 

[jim mcnamara]

How about the Epocholypse on January 19 2038 - end of 32 bit time_t for UNIX.
https://en.wikipedia.org/wiki/Year_2038_problem

@anorlunda is right...

 

[Borg]

Looks like no work email for me this week.

 

[anorlunda]

Peter G Neumann, moderator of the ACM Risks forum, said this.

[Bug? Well, more like the 20-year window that was used in 2002 rolled
over. That's not a bug, it's a standard temporary fix that expired. PGN]

That's very true, and it is an underlying cause of so many of these date-related bugs. Developers, and sometimes the Requirements, can not envision the software they write being used so far into the future.

I normally hate regulation, but in this case an idea comes to mind. Software that handles dates should come with an expiration date set up front. Then require that it must be replace before the expiration date. (Windows 7 and Windows 98 users will scream. )

I'm personally guilty of a "bug" caused by expiration. I wrote graphics programs for ASEA in Sweden. Projects there were fond of using 3 digit week numbers in project planning. Last digit of the year, plus week number within the year. So 1/9/2022 would be week 202. (Or maybe week 152 or 203 because New Years Day may be in the last week of the previous year, or the first week of the new year.) I tried and failed to find the algorithm used for that New Years Day handling. Those were pre-Internet days.

In desperation, I found printed calendars showing week number up to 5 years in the future. So I programmed those dates in, and put a note in BOLD text in the manual that the week number function would expire after 5 years. When the 5 years expired, the users finally looked at the manual and they were very angry at me.

 

[OmCheeto]

Speaking of bugs...

Since when are the time stamps here at PF predictive?
Or is Astronuc a time lord?

 

[Svein]

There seems to be no end to the number of times people can screw up managing dates. Perhaps that's the real answer, date bugs are perpetual.

At least the Network Time Protocol version 4 (rfc5905) has added a separate "era" number where each era is about 136 years.

Excerpt from rfc5905
Timestamps are unsigned values, and operations on them produce a result in the same or adjacent eras. Era 0 includes dates from the prime epoch to some time in 2036, when the timestamp field wraps around and the base date for era 1 is established. In either format, a value of zero is a special case representing unknown or unsynchronized time. The table below shows a number of historic NTP dates together with their corresponding Modified Julian Day (MJD), NTP era, and NTP timestamp.

Date​	MJD​	NTP Era​	NTP Timestamp Era Offset​	Epoch​
1 Jan -4712​	-2,400,001​	-49​	1,795,583,104​	1st day Julian​
1 Jan -1​	-679,306​	-14​	139,775,744​	2 BCE​
1 Jan 0​	-678,491​	-14​	171,311,744​	1 BCE​
1 Jan 1​	-678,575​	-14​	202,939,144​	1 CE​
4 Oct 1582​	-100,851​	-3​	2,873,647,488​	Last day Julian​
15 Oct 1582​	-100,840​	-3​	2,874,597,888​	First day Gregorian​
31 Dec 1899​	15019​	-1​	4,294,880,896​	Last day NTP Era -1​
1 Jan 1900​	15020​	0​	0​	First day NTP Era 0​
1 Jan 1970​	40,587​	0​	2,208,988,800​	First day UNIX​
1 Jan 1972​	41,317​	0​	2,272,060,800​	First day UTC​
31 Dec 1999​	51,543​	0​	3,155,587,200​	Last day 20th Century​
8 Feb 2036​	64,731​	1​	63,104​	First day NTP Era 1​

 

[anorlunda]

At least the Network Time Protocol version 4 (rfc5905) has added a separate "era" number where each era is about 136 years.

That's great. Now all we need to do is to update all the world's software written before version 4. (By the way, it still sounds like we are assuming today's software will not be used past the end of era 1.)

 

[Svein]

(By the way, it still sounds like we are assuming today's software will not be used past the end of era 1.)

Oh, it will, no doubt. It was possible to do some workaround, though. I was asked to do an NTP client in 2008 and I told them about the 2036 problem (NTP ver. 4 hadn't been released yet). I was told that 2036 must be fixed somehow! What I did, was to explicitly assume that the year 2000 would never again appear in an NTP 3 message, so if the timestamp would seem to indicate a date before 2000, it would be due to a rollover. That would work until about 2100 (when I would not be around). Of course, the workaround was marked in the comments - somebody might actually look at the code someday.

 

[anorlunda]

Not bad. At least you thought about it.

Of course, the workaround was marked in the comments - somebody might actually look at the code someday.

A common problem exposed in 90s Y2K investigations is that legacy software tends to get wrapped in a shell of newer software. Then the wrappers are wrapped until the whole thing takes on the structure of an onion.

Nobody remembers what the exact functions of the innermost core were, nor the active dependencies of the outermost layer on the core. Sometimes there are zero residual dependencies, but nobody is certain enough to try cutting out the core. Modern software engineering practices are never applied retroactively, they are used to create additional layers.

Nearly ubiquitous in the 90 findings was that no person in the organization was responsible for remaining familiar with what and how the innermost layers worked except during an emergency crisis.

Since the 90s, the practice of providing wrappers has only increased in popularity. Some of my favorite Python packages are wrappers around C code which wraps FORTRAN modules. Some recent virus scares come from open source modules buried many layers deep in the stack of things.

 

[DaveC426913]

Indeed. Anyone Remember the left-pad debacle a few years ago?

EA nobody of a programmer deleted 11 lines of his own code in a code repo, and half the web stopped working.

The story around it was so much more though. His project was effectively stolen from him by the very code repo - whose purpose was to protect his work - because of a corporate bully. Such hubris.

https://www.google.com/amp/s/qz.com...nternet-by-deleting-a-tiny-piece-of-code/amp/