I've got time on my mind

[chalsall]

MOD NOTE: This thread spun off from the Hmmm.. thread: https://www.mersenneforum.org/showthread.php?p=597134

A friend of mine shared this with me today. Apparently, his New Year was also a little bit busy...

Please see this and this and this...

Please forgive me for this, but... Fsck me!

Really? You only had one job to do, and you didn't even get that correct!!!

And people pay big money for this level of QA? Because they think they have "covered their butts with paper" and can sue someone if something goes wrong...

Linus has this (and many other things) correct... Given enough eyes, all bugs are shallow.

[xilman]

Originally Posted by chalsall

Please see this and this and this

I was on standby for MSRC at the changeover from 1999 to 19100.

Nothing affected us, but I did observe the changeover just noted --- in a clock display in NZ and not one controlled by MSFT software. Someone used Perl '.' --- which is string concatenation --- instead of '+' which would have performed arithmetic addition.

OTOH, MSFT-UK HQ lost all power at precisely 12 noon on the 99th day of 1999. It might have been a co-incidence ...

Now waiting for the s2G problem to hit. Just a little over 16 years to go.

[chalsall]

Originally Posted by xilman

Now waiting for the s2G problem to hit. Just a little over 16 years to go.

I hope this is taken the way it is intended...

Those who are serious about their compute model what can happen. And then constrain the problem space so that it can be determistic.

The representation of time is a long-ago solved problem.

The fact that one of our major providers didn't even understand the fundamentals of this idea is at best preposterous.

Over.

[Uncwilly]

The 2038 problem has already arrived:
There was a financial institution that had to patch things, because their calculations for deposits to cover people's retirements ran into the limit. The "plan for retirements in XX years for person" calculations put that retirement in the forbidden zone. I heard the programmer who was called in and had to fix/work around the issue over a weekend. Unfortunately I believe the podcast I heard has move over to only on 🟢 -ify

[Dr Sardonicus]

(My emphasis)

Originally Posted by chalsall

A friend of mine shared this with me today. Apparently, his New Year was also a little bit busy...

Please see this and this and this...
<snip>

It's not clear how long the buggy date storage had been in place, but judging from the two affected versions, it was possibly introduced when Exchange Server 2016 was under development.

So, they wrote the code with a time variable that was only good for at most five years, and nobody noticed...

[chalsall]

Originally Posted by Dr Sardonicus

So, they wrote the code with a time variable that was only good for at most five years, and nobody noticed...

Yup. And...

Empirically, absolutely no serious peer review was done on the code-paths.

This code was released "into the wild" onto many mission-critical systems before anyone noticed that things were not working "nominally"...

An excellent example of how not to do things...

[retina]

Originally Posted by Dr Sardonicus

... only good for at most five years ...

So how many bits should be used?

Assuming the proton does decay then the heat death of the universe is estimated at a maximum of approximately 10¹⁰⁶ years. Allowing for nanosecond resolution that is about 407 bits of storage for the date fields. 407 bits should be enough for anyone.

Things get more crazy if the proton doesn't decay. Estimates vary, and the times could be arbitrary large. Maybe everyone should switch to arbitrary precision formats for the dates?

[chalsall]

Originally Posted by retina

So how many bits should be used?

Exactly as many as are needed.

[Uncwilly]

Just enough to avoid the Y10K problem. And no more.

[Dr Sardonicus]

Originally Posted by retina

So how many bits should be used?
<snip>

IMO it's not a matter of how many bits you should use, but knowing how many you've got, when that won't be enough, and providing for that contingency.

With the Micro$oft problem, an error message that told the story was, Can't Convert "2201010001" to long.

Using the last two digits of a year number as the lead digits of a 10-digit number, then converting that to a long integer, is worthy of the adjective "harebrained" in one of the articles chalsall linked to. It artificially limited the usefulness of the long integer provided.

The s2G problem, AKA the 2038 problem, involves a long integer also, but a long integer that represents the number of seconds since 00:00:00 UTC 1 January 1970. It doesn't manifest until one second after 3:14:07 UTC 19 January 2038, when it will suddenly be 20:45:52 UTC Friday, 13 December 1901. As has been pointed out, programs dealing with dates after 3:14:07 UTC 19 January 2038 have already run into the problem.

This problem already has an interim fix of using unsigned integers. Recompiling the time library using 64-bit signed integers would provide long term relief.

The Y2K problem was known long before it manifested, and people did get to work on it before it actually hit, albeit rather late in the game in many cases.

With the Exchange Server problem, it seems that the limitation issue wasn't even considered until it manifested.

Rather than trying to devise a variable to represent time that will be valid for all time, I think what is needed is to have the time programming check when the variable's limit of validity is being approached or exceeded, and handle it appropriately.

A 64-bit signed integer has maximum positive value 2⁶³ - 1, which accommodates the number of seconds in 292,277,265,436 years. That will see the Earth incinerated, and Mr. Sun well into cooling off after becoming a white dwarf.

IMO a 64-bit signed integer is more than sufficient.

Because Mr. Sun is gradually getting brighter, the earth will only remain inhabitable for something on the order of 100 million years. Shave off 7 or 8 bits.

A possibly much lower limit is the length of time our species remains technically capable enough for the question of "how many bits" to matter. "Enough to avoid the Y10K problem" may well be sufficient for that.

[xilman]

Originally Posted by Dr Sardonicus

A 64-bit signed integer has maximum positive value 2⁶³ - 1, which accommodates the number of seconds in 292,277,265,436 years. That will see the Earth incinerated, and Mr. Sun well into cooling off after becoming a white dwarf.

IMO a 64-bit signed integer is more than sufficient.

IMO, and in that of others who have thought deeply about representation of time, it is not.

Use two 64-bit integers. One signed which counts seconds from an agreed upon sensible epoch. The other is unsigned and counts 2^-64 seconds since the last transition of the first counter. This is, of course, equivalent to using a 128-bit signed integer.

Some consider even that to be insufficient because it takes light only 2^-76 seconds to travel the diameter of a nucleon and physicists already measure time to that precision. The solution is clear: the signed quantity counts 2^-20 seconds (about a microsecond) from an epoch and the unsigned 2^-84 seconds. We now have adequate range and adequate uniform precision.