mersenneforum.org  

Go Back   mersenneforum.org > Fun Stuff > Lounge

Reply
 
Thread Tools
Old 2022-01-04, 20:33   #1
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

243078 Posts
Default There is a reason I don't use propretary software...

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.

Last fiddled with by Uncwilly on 2022-01-05 at 14:37
chalsall is offline   Reply With Quote
Old 2022-01-04, 21:25   #2
xilman
Bamboozled!
 
xilman's Avatar
 
"๐’‰บ๐’ŒŒ๐’‡ท๐’†ท๐’€ญ"
May 2003
Down not across

2C1916 Posts
Default I've got time on my mind

Quote:
Originally Posted by chalsall View Post
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.

Last fiddled with by xilman on 2022-01-04 at 21:26
xilman is online now   Reply With Quote
Old 2022-01-04, 22:01   #3
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

101000110001112 Posts
Default

Quote:
Originally Posted by xilman View Post
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.
chalsall is offline   Reply With Quote
Old 2022-01-04, 22:10   #4
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101ร—103 Posts

3×31×113 Posts
Default

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
Uncwilly is offline   Reply With Quote
Old 2022-01-04, 22:58   #5
Dr Sardonicus
 
Dr Sardonicus's Avatar
 
Feb 2017
Nowhere

3·17·113 Posts
Default

(My emphasis)
Quote:
Originally Posted by chalsall View Post
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>
Quote:
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...

Dr Sardonicus is offline   Reply With Quote
Old 2022-01-04, 23:28   #6
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

243078 Posts
Default

Quote:
Originally Posted by Dr Sardonicus View Post
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...
chalsall is offline   Reply With Quote
Old 2022-01-05, 00:02   #7
retina
Undefined
 
retina's Avatar
 
"The unspeakable one"
Jun 2006
My evil lair

3·19·113 Posts
Default

Quote:
Originally Posted by Dr Sardonicus View Post
... 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 10106 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?
retina is online now   Reply With Quote
Old 2022-01-05, 00:31   #8
chalsall
If I May
 
chalsall's Avatar
 
"Chris Halsall"
Sep 2002
Barbados

11·13·73 Posts
Default

Quote:
Originally Posted by retina View Post
So how many bits should be used?
Exactly as many as are needed.
chalsall is offline   Reply With Quote
Old 2022-01-05, 00:48   #9
Uncwilly
6809 > 6502
 
Uncwilly's Avatar
 
"""""""""""""""""""
Aug 2003
101ร—103 Posts

1050910 Posts
Default

Just enough to avoid the Y10K problem. And no more.
Uncwilly is offline   Reply With Quote
Old 2022-01-05, 02:12   #10
Dr Sardonicus
 
Dr Sardonicus's Avatar
 
Feb 2017
Nowhere

3·17·113 Posts
Default

Quote:
Originally Posted by retina View Post
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 263 - 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.
Dr Sardonicus is offline   Reply With Quote
Old 2022-01-05, 06:03   #11
xilman
Bamboozled!
 
xilman's Avatar
 
"๐’‰บ๐’ŒŒ๐’‡ท๐’†ท๐’€ญ"
May 2003
Down not across

3×53×71 Posts
Default

Quote:
Originally Posted by Dr Sardonicus View Post

A 64-bit signed integer has maximum positive value 263 - 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.

Last fiddled with by xilman on 2022-01-05 at 06:06 Reason: Add "128-bit" sentence.
xilman is online now   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
Soap Box clutterbot - What's on your mind? Squeak up! only_human Soap Box 106 2020-11-08 12:44
CUDA Install errors...HELP...never mind petrw1 GPU Computing 2 2016-03-06 13:39
Georgia on my mind davieddy Soap Box 5 2008-08-18 22:30
Mind Boggling Number mfgoode Math 22 2004-02-23 10:39

All times are UTC. The time now is 13:18.


Mon May 16 13:18:06 UTC 2022 up 32 days, 11:19, 1 user, load averages: 1.45, 1.23, 1.24

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.

โ‰  ยฑ โˆ“ รท ร— ยท โˆ’ โˆš โ€ฐ โŠ— โŠ• โŠ– โŠ˜ โŠ™ โ‰ค โ‰ฅ โ‰ฆ โ‰ง โ‰จ โ‰ฉ โ‰บ โ‰ป โ‰ผ โ‰ฝ โŠ โŠ โŠ‘ โŠ’ ยฒ ยณ ยฐ
โˆ  โˆŸ ยฐ โ‰… ~ โ€– โŸ‚ โซ›
โ‰ก โ‰œ โ‰ˆ โˆ โˆž โ‰ช โ‰ซ โŒŠโŒ‹ โŒˆโŒ‰ โˆ˜ โˆ โˆ โˆ‘ โˆง โˆจ โˆฉ โˆช โจ€ โŠ• โŠ— ๐–• ๐–– ๐–— โŠฒ โŠณ
โˆ… โˆ– โˆ โ†ฆ โ†ฃ โˆฉ โˆช โŠ† โŠ‚ โŠ„ โŠŠ โŠ‡ โŠƒ โŠ… โŠ‹ โŠ– โˆˆ โˆ‰ โˆ‹ โˆŒ โ„• โ„ค โ„š โ„ โ„‚ โ„ต โ„ถ โ„ท โ„ธ ๐“Ÿ
ยฌ โˆจ โˆง โŠ• โ†’ โ† โ‡’ โ‡ โ‡” โˆ€ โˆƒ โˆ„ โˆด โˆต โŠค โŠฅ โŠข โŠจ โซค โŠฃ โ€ฆ โ‹ฏ โ‹ฎ โ‹ฐ โ‹ฑ
โˆซ โˆฌ โˆญ โˆฎ โˆฏ โˆฐ โˆ‡ โˆ† ฮด โˆ‚ โ„ฑ โ„’ โ„“
๐›ข๐›ผ ๐›ฃ๐›ฝ ๐›ค๐›พ ๐›ฅ๐›ฟ ๐›ฆ๐œ€๐œ– ๐›ง๐œ ๐›จ๐œ‚ ๐›ฉ๐œƒ๐œ— ๐›ช๐œ„ ๐›ซ๐œ… ๐›ฌ๐œ† ๐›ญ๐œ‡ ๐›ฎ๐œˆ ๐›ฏ๐œ‰ ๐›ฐ๐œŠ ๐›ฑ๐œ‹ ๐›ฒ๐œŒ ๐›ด๐œŽ๐œ ๐›ต๐œ ๐›ถ๐œ ๐›ท๐œ™๐œ‘ ๐›ธ๐œ’ ๐›น๐œ“ ๐›บ๐œ”