Comment On Classic WTF: The Harbinger of the Epoch

If it was January 19, 2038, you wouldn't be claiming "First!". I doubt any of us could. ;)

print "I suggest finding a new vendor!"
sleep 1000000000
cls #Erase comment after 30+ years

Billionth!

(Er, mind you, that's a 'Murkin billionth. .elsewhere, read that as thousand-millionth....)

but the fix was pretty simple: the vendor shaved a zero off the sleep command.

WTF!? How about just removing the last two lines of the script? How useful is it to have your application shut down/crash at some random moment in the distant future?

It would appear this one is fixed, at least in modern ubuntu. Sleep 10000<snip screenful of zeroes> seems to sleep just fine.

It's always best to let sleeping oracles lie.

Jordi:

but the fix was pretty simple: the vendor shaved a zero off the sleep command.

WTF!? How about just removing the last two lines of the script? How useful is it to have your application shut down/crash at some random moment in the distant future?

Golden Rule No. 1: Never do today what you can put off until sometime in the future. Do you want to be out of a job?
A flawless system that never crashes doesn't bring in any revenue.

Happy New Year, and have fun fixing those "Date Not Found" bugs created by your predecessors who never would have thought their software would see 2009.

Or hardware: http://gizmodo.com/5121311/30gb-zunes-failing-everywhere-all-at-once. Happy new year, Microsoft!

Jeff:

A flawless system that never crashes doesn't bring in any revenue.

Which is why Linux has yet to take over the world...

Looks like a poor man's approach on implementing a SIGTERM shutdown hook for a service => The shutdown script will send SIGTERM on all processes remaining after executing the shutdown scripts. Some processes even refuse to accept that, but "sleep x" will do. Once sleep exited oracle gets terminated.

The real WTF is, why they didn't just put "oracle stop" into a shutdown script.

Jordi:

WTF!? How about just removing the last two lines of the script? How useful is it to have your application shut down/crash at some random moment in the distant future?

The standard assumption of the maintenance programmer is that if something looks completely nonsensical, it is probably that way for a reason, and shouldn't be tampered with for fear it could cause a problem.

In many cases this is true. Chances are good that there is a better, cleaner solution to the problem, but figuring out first what the problem was that the ugly kluge was meant to solve, and then figuring out the more elegant solution to that problem is a lot of work. Removing a zero is not a lot of work. Ergo, rather than hurting your brain trying to figure out why this mystical incantation was originally uttered, or putting your butt on the line by assuming that the original developer was a total moron and added these two lines for no reason whatsoever, you remove a zero, and go back to sleep.

Such is the life of the third class programmer.

I find this re-post very amusing this morning as news of this spreads:

http://arstechnica.com/news.ars/post/20081231-30gb-zunes-prepare-for-new-year-by-locking-up.html

I used to a Tier 2 agent for Zune Support - glad I don't work there anymore, as the phones are going to be ringing off the hook!

Not to excuse the lack of comment, but could that sleep have been put in there because of some historical issues Oracle's had with the uptime command?

Jordi:

but the fix was pretty simple: the vendor shaved a zero off the sleep command.

WTF!? How about just removing the last two lines of the script? How useful is it to have your application shut down/crash at some random moment in the distant future?

Remind me to never hire you to write a random number generator for me.

Could someone explain "2^31-10^9" means? I never was very good at maths. Also, why is time stored as an epoch, and what will the solution to the problem be (in 2038)?

CAPTCHA: paratus - that act of repeating what was just said.

Hmmmm...

Do you suppose they'll fix this permanently once enough 0's have been shaved off?

That is ...

   sleep 10000000 ---> 115.7 days

   sleep 1000000 ---> 11.57 days

   sleep 100000 ---> 27.78 hours

   sleep 10000 ---> 2.78 hours

   sleep 1000 ---> 16.67 minutes

... I mean, this could give you a whole new definition for, "Problem came back."

http://xkcd.com/376/

tuna:

It would appear this one is fixed, at least in modern ubuntu. Sleep 10000<snip screenful of zeroes> seems to sleep just fine.

I assume that's x86-64 Ubuntu, yes? The problem is with 32-bit time_t, resolved by making time_t a 64-bit integer.

Justin Epoch Fail:

http://xkcd.com/376/

Get him!

rosko:

tuna:

It would appear this one is fixed, at least in modern ubuntu. Sleep 10000<snip screenful of zeroes> seems to sleep just fine.

I assume that's x86-64 Ubuntu, yes? The problem is with 32-bit time_t, resolved by making time_t a 64-bit integer.

Based on quick rough calculations (2^64 google search), even 64-bit ints wouldn't fit more than 20-digit numbers. "Screenful of zeroes" sounds like more than 20 (especially when you consider a standard terminal is 80 characters wide). So it seems likely that the problem has actually been fixed (whether by capping it at the maximum possible value or some other means)

Schmuli:

Could someone explain "2^31-10^9" means? I never was very good at maths. Also, why is time stored as an epoch, and what will the solution to the problem be (in 2038)?

See it as (2^31)-(10^9), which is "(2 to the power 31) minus (10 to the power 9)". Basically, 2 billion (approx.) minus 1 billion.

Time on a computer is normally stored as a number of seconds since a particular date. That date is known as the "epoch" of that date system.

Most systems have been using 32-bit dates, which only gives you around 136 years (2^31 seconds, or around 4 billion seconds). In 2038, time will run out for UNIX and Linux systems still using 32-bit dates. Other OSes will vary depending on the Epoch, which can be in 1900, 1901, 1970 or any other year of choice.

The solution is to store the dates using more bits, e.g. 64 bits.

Over a decade ago I was using Aegis 9.7 in test equipment based on Apollo workstations, when I became aware of the 'date bug' in that OS.

Some far sighted OS designer had based the date routines on a 31-bit counter which was expected to overflow on 2 November 1997. I forget the exact time.

The consequence of the overflow was that if the workstation was shut down, it wouldn't boot again.

Since the system real time clock could only be set when the OS wasn't running, I was able to change the date, verify the problem, and reset the date to something which would allow a reboot.

For many years we operated in a time-warp, with the clocks set to 16 years in the past.

2^31 is two raised to the 31st or 2,147,483,648. The reason it is important is that a signed 32 bit integer can only hold up to that number minus one before overflowing (to -1). 10^9 is ten raised to the nineth (1,000,000,000). If you take the current time in seconds since 1970 (the epoch time) 1,230,795,313 and add 1,000,000,000 to it you get 2,230,795,313 which is larger than what can be stored in a signed 32 bit integer, so it overflows (due to two's complement) to -2,064,171,983. A sleep for a negative value returns immediately.

As for why we use the epoch, well, how else are you going to store it? A string? Yeah, that worked real well for the COBOL guys didn't it? Seconds since a fixed point in time is a good solution as it is easy to store and do math with.

The solution is to move to using a 64 bit integer, which should last us until the heat death of the universe (or an eleven digit year, which ever comes first). Hopefully, if we have found a way to reverse entropy by then, we will switch to a 128 bit integer before it becomes an issue.

Daniel Beardsmore:

Schmuli:

Could someone explain "2^31-10^9" means? I never was very good at maths. Also, why is time stored as an epoch, and what will the solution to the problem be (in 2038)?

Most systems have been using 32-bit dates, which only gives you around 136 years (2^31 seconds, or around 4 billion seconds)

Actually half that, since Unix uses a signed value, so the first bit is the sign bit. With an epoch of 1970 that gives a date range from 1902 to 2038

Chas. Owens:

Seconds since a fixed point in time is a good solution as it is easy to store and do math with.

Pain in the arse with the leap second though.

Y2038 problem will be bigger than Y2K for several reasons. It's more fundamental, being at the heart of the operating system rather than just numbers in a database. It's probably more widespread - any 32 bit Unix system suffers this issue. And it's harder for the layperson to understand, so there likely won't be as much awareness of it. Oh, and in some timezones it'll hit in the middle of the working day (assuming systems using UTC as their system clock, as they should).

True, there's 30 years for problematic systems to disappear. But the developers of Y2K bugged software didn't think it would still be in use in 2000.

Thanks for explaining that.

Does this mean therefore that any date calculations are really mathematical operations on the value of the epoch? Going back before the epoch is not a problem, because I just store a negative value?

I noticed in Reflector that the DataTime object stores its data as a 'ulong', which is an unsigned 64bit integer. Can .NET applications still be affected by the epoch overflow issue? Is it dependent on the underlying OS? More to the point, is Windows still using 32bit integers for the date, or has it upgraded already? Also, what about the BIOS clock, isn't the OS taking its value from there, meaning this isn't an OS issue, but rather a BIOS one?

Why was the sleep and stop there to begin with? Perhaps it was initially put in during development but with a shorter sleep to test something. Close to release somebody might have realized it needed to be changed, but it was deemed too dangerous to make any design changes that close to release, so rather than removing the lines it was decided that increasing the sleep time was safest - a real fix could always be done later.

Time passes everybody forgets about a problem that needs to be fixed and suddenly it blows up. When the problem becomes clear it was decided that during an emergency it is not a good idea to make any design changes, so it was decided that decreasing the sleep time was safest. A real fix would of course be necessary at a later point once the emergency was over.

If my guesses above are correct, I hope the people currently responsible for this software read this article, because they have probably forgotten that they have a pending problem that needs to be fixed.

BTW. The problem did sound somewhat similar to: http://en.wikipedia.org/wiki/Year_2038_Problem#Known_problems

m0ffx:

Daniel Beardsmore:

Most systems have been using 32-bit dates, which only gives you around 136 years (2^31 seconds, or around 4 billion seconds)

Actually half that, since Unix uses a signed value, so the first bit is the sign bit. With an epoch of 1970 that gives a date range from 1902 to 2038

Maybe you're using a different base to me, but I make 2038 - 1902 = 136. Daniel was perfectly correct: he merely omitted system-specific information (which is fair enough given that he was talking about 32-bit systems in general).

The problem was probably something checking if the script terminated and causing more problems.

CoyneT:

Hmmmm...

Do you suppose they'll fix this permanently once enough 0's have been shaved off?

I'm sure they'll fix it permanently once they have a dedicated 2038 bug budget. If they do get down to 1000000s before that happens, there will be someone there who remembers the last time, and the fact that neither Caspar nor his predecessor put a warning anywhere will not matter.

Another WTF is that some of you can actually think about all of these numbers on the day of Hangover. ;)

CAPTCHA: damnum - Too approprate for words (or numbers as the case may be).

What no one's posted when this failure would have occurred yet? Shame on you, and you call yourselves geeks. Tut-tut. ;-)

It's Saturday the 13th of May 2006 at 01:27:28 UTC by the way.

Does this mean therefore that any date calculations are really mathematical operations on the value of the epoch? Going back before the epoch is not a problem, because I just store a negative value?

Yes, it's basically simple math - if you want to go forward one day, just add 86400 to the value, and so on.

Going to the time before the epoch depends entirely on whether the value is stored as an unsigned or a signed value. Unix uses signed values, so you can use negative numbers to go to pre-1970 dates.

I noticed in Reflector that the DataTime object stores its data as a 'ulong', which is an unsigned 64bit integer. Can .NET applications still be affected by the epoch overflow issue?

Pretty much all applications can, as long as the values are stored in a fixed-size variables, which is (as you can see) the case pretty much all the time.

It just takes a really freaking long time if it's stored in a 64-bit integer. As said, signed 32-bit Unix date will wrap around in January 19, 2038. 64-bit Unix date will wrap around in December 4, 292277026596. They may have invented something better by then, but I'm not sure if I should be optimistic or pessimistic about that.

Is it dependent on the underlying OS? More to the point, is Windows still using 32bit integers for the date, or has it upgraded already? Also, what about the BIOS clock, isn't the OS taking its value from there, meaning this isn't an OS issue, but rather a BIOS one?

As a Linux guy I regrettably don't know the specifics on Windows. I'm just kind of assuming that 32-bit OSes use 32-bit variables and the 64-bit OSes have migrated already. Someone please correct me.

Anyway:

Computers are hell of a multilayered abstract beasts! There are multiple layers of date storage. The computer has a hardware clock, the operating system has its own clock (operating systems are largely portable these days and they don't want to rely on any specific kind of a hardware clock - times change!), the low-level OS API uses one kind of abstraction, the various other programming languages on top of that use their own APIs, and all of the various bits along this glorious gigantic way use their own way of storing and processing the number.

None of these have necessarily any bearing on whether or not the other parts of the chain have any specific limitations. Your standard library can be perfectly capable of handling dates in 64-bit format... while your operating system, likewise a modern thing, is busy working around the deficiencies of your antiquated BIOS. The OS grins, tells the application the correct time value, while cursing at the machine behind the application's back. Hypothetical, but it can happen.

Tim:

What no one's posted when this failure would have occurred yet?

I posted a link to a Wikipedia article with the date.

64-bit Unix date will wrap around in December 4, 292277026596. They may have invented something better by then[...]

Time travel!

What everyone seems to miss is that many industries (specifically the financial industry) often needs to refer to dates 30 years in the future. For example, mortgages... As such, this is already an issue for many financial institutions and other companies that regularly need to refer to and store future dates.

Yeah, let's get the Zune New Years bug up on dailywtf. I mean, I know bugs are gonna happen sometimes, but when we have an event where *all* of a certain category of mp3/general media player fail at the same time for real, well I think that's worthy of coverage here.

--
Furry cows moo and decompress.

m0ffx:

Pain in the arse with the leap second though.

Y2038 problem will be bigger than Y2K for several reasons. It's more fundamental, being at the heart of the operating system rather than just numbers in a database. It's probably more widespread - any 32 bit Unix system suffers this issue. And it's harder for the layperson to understand, so there likely won't be as much awareness of it. Oh, and in some timezones it'll hit in the middle of the working day (assuming systems using UTC as their system clock, as they should).

True, there's 30 years for problematic systems to disappear. But the developers of Y2K bugged software didn't think it would still be in use in 2000.

We might be ok though if enough systems have switched over to 64-bit computing by then. Also, there's actually a lot *more* awareness of this problem among the people that would have to fix it than I believe there was for the Y2K bug. Of course, I suspect The Media will still hype it up during the last few years, and especially months, before the Big Event.

Embedded Linux/Unix systems are probably at the biggest risk for meltdown since they're hard to get at and they tend to get forgotten about. For example: do you know which version of which OS *your* home router uses?

--
Furry cows moo and decompress.

Is it dependent on the underlying OS? More to the point, is Windows still using 32bit integers for the date, or has it upgraded already? Also, what about the BIOS clock, isn't the OS taking its value from there, meaning this isn't an OS issue, but rather a BIOS one?

32-bit Windows has always used 64-bit time, but it has a resolution of 100ns instead of 1 second, so it is more precise, but goes through them much more quickly. The valid date range is 1601 through 30827.

since the time of start is somewhat random the time of the crash is also random if you dont have started the application yet

Ozz:

Jeff:

A flawless system that never crashes doesn't bring in any revenue.

Which is why Linux has yet to take over the world...

Actually, this could be the truest thing I've read all week.

Well, he's got 35 years and 11 months to find another fix:

Sat Nov 18 17:27:28 GMT 2034

Iain:

Well, he's got 35 years and 11 months to find another fix:

Sat Nov 18 17:27:28 GMT 2034

doh! that should of course be 25 years!!

...the number of seconds since the beginning of The Epoch...

That's redundant, the Epoch is a time which marks the beginning of something, not a period of time. Unless of course you are referring to the beginning of the second, as opposed to the middle or the end of the second in question.

Schmuli:

Thanks for explaining that.

Also, what about the BIOS clock, isn't the OS taking its value from there, meaning this isn't an OS issue, but rather a BIOS one?

If possible, networked computers get their time from the internet, using NTP. BIOS time is used at boot time, and as a backup, if the network time is not available.

Accurate network time is required for some security protocols. Since the BIOS time may not be accurate, or even correct, servers may not communicate if network time is not available.

This is not a problem for workstations, because workstations normally assume that network time may not be available, and don't implement services that fail in its abscence.

WWWWolf:

... 64-bit Unix date will wrap around in December 4, 292277026596.

I think I'll leave that for the Y3hG programmers to worry about.

Wyrd:

Also, there's actually a lot *more* awareness of this problem among the people that would have to fix it than I believe there was for the Y2K bug.

The problem is it's a painfull bug to fix because you can't change the size of standard C types without breaking the ABI.

So the only way to fix it is to either break the ABI (meaning all apps need to be recompiled at once) or introduce new APIs and modify the apps to use them.

We might be ok though if enough systems have switched over to 64-bit computing by then.

64 bit apps on a 64 bit unix like OS will most likely be fine because the ABIs for 64 bit apps tend to use 64 bit time_t. 32 bit apps on a 64 bit OS will have the same problems as they did on a 32 bit OS.

Embedded Linux/Unix systems are probably at the biggest risk for meltdown since they're hard to get at and they tend to get forgotten about.

And they are likely to remain 32 bit for a long time. I don't see most embedded systems needing more than 4 gigs of ram.

DaveAronson:

'Murkin

It's "merkin", not "'Murkin". "'Murkin" is a representational spelling of "American" into English English, while "merkin" is...

I suggest you look it up. With pictures.

Jeff:

Golden Rule No. 1: Never do today what you can put off until sometime in the future. Do you want to be out of a job?

That's the general idea, yes. Do myself out of a job by being super-efficient. Doing a great job gets you cooler jobs later on.

Jeff:

A flawless system that never crashes doesn't bring in any revenue.

Yes it does. For the owner of that system.

A question for you: You're not located in Redmond, WA, are you?

WWWWolf:

[...] 64-bit Unix date will wrap around in December 4, 292277026596. [...]

I'm willing to bet that the leap year rules will have changed by then! So i won't hold my breath on it being exactly on the 4th of December... ;-)

&nbsp;&nbsp;
货架racking.&nbsp;&nbsp; 仓储货架
南京货架设备要产品包括:重型货架
,阁楼货架,超市Shelf,重量型货架,横梁式货架,驶入式货架... 仓储笼
货架的形式与材料 · 立体仓库 · 货架厂
物流规划设计的步骤与程序（货架的设计... 中国物流行业呈现三足鼎立抢市场 · 亚洲第三方物流的现状和发展 ... 托盘
抽出式货架系列 · 重力式 货架/推入式货架钢托盘
移动式货架 · 阁楼式货架 · 悬臂式货架
系列 长件物料储存货架&nbsp;货架公司。