Bruce Schneier | |||||||||||
Schneier on SecurityA blog covering security and security technology. « AT&T Rewrites its Privacy Policy | Main | Friday Squid Blogging: Stir-Fried Squid with Shrimp Sauce » June 23, 2006Unix Date BugI've long known about the possible Unix date issue, but this is the first I've heard of an actual bug due to the Unix time epoch rolling over in 2038. Posted on June 23, 2006 at 12:56 PM • 36 Comments To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter. Victor Bogado • June 23, 2006 1:35 PM When are we going to start using 64bits for this? I find the unix date very clever and simple. It does not rely on local standards or calendary details like when there are leap seconds. Even with todays 32 bits systems we could update the date to 64 bits, it is a long long in the linux ABI for C, and create a deprecated API to read and set the 32 bits that would turn out a warning to the compiler. Michael Lee • June 23, 2006 1:38 PM Just as Y2K provided for the retirement of a bunch of COBOL programmers, the 2038 bug (time to think of a sexy name for it now) will provide it for C programmers. radiantmatrix • June 23, 2006 1:43 PM @Victor: The patch is ready, and some UNIX-likes (including Linux, IIRC) already use 64-bit dates with a mere compile-time option. Fortunately, extending to 64 bits will only cause problems with applications that depend on the value "wrapping around", which is pretty rare. Stephen Smoogen • June 23, 2006 1:45 PM Another solution with the Unix date for systems unable to be moved to 64 bit time would be to move the Unix Epoch up to say Jan 1, 2001 which would move the day of reckoning to 2068 Anonymous • June 23, 2006 1:54 PM >Another solution with the Unix date for systems unable to be moved to 64 bit time would be to move the Unix Epoch up to say Jan 1, 2001 which would move the day of reckoning to 2068
Ross Patterson • June 23, 2006 1:58 PM @Victor: The problem, just like Y2K, isn't so much about the current date as it is about all the dates that are stored in existing data and the processing of them. In 2037 we're gonna be partying like it was 1999 all over again. With any luck, we'll be just as successful the second time around and everyone will ask "Where's the Earth-shattering kaboom? There's supposed to be an Earth-shattering kaboom!" again. Ross Patterson • June 23, 2006 2:02 PM @Anonymous: >oh oh can you imagine how many systems THAT fix would break!!! Yup, it's happened in the past. In the 1970s, IBM mainframes shifted their epoch from 1960-01-01 to 1900-01-01. The cleanup work was huge. The dominant date format was yyddd (remember Y2K?), but there were plenty of these "number of days since the epoch" dates lying around too. Jarrod • June 23, 2006 2:12 PM @Ross: One would hope, but consider the number of backbone systems running *nix that management (and maybe even some of the engineering staff) is terrified of rebooting for fear it will never again come back. With any luck, this will include something harmless that nonetheless causes some interesting fireworks. :) Stu Savory • June 23, 2006 2:27 PM My funniest Y2K story (I had duty that night) : When the date rolled over, the fire alarm in (all the branch offices of) a certain bank, whom I shall leave nameless to protect the guilty, triggered. So for safety's sake, the security SW unlocked all the doors and even opened all the sliding doors :-) Luckily, the bank had the foresight to have staff on site in every branch at the rollover. Woody • June 23, 2006 2:36 PM Luckily, 64-bit time (for system time) gives us enough leeway to actually be free from this problem. Java's internal time is 64-bit, and is milliseconds since the epoch (fuzzy on the exact epoch they used). But it's good for an insane amount of time (500 million years, if I did my math correctly). 2^64 / (365*24*60*60*1000) YEAR 2000 (Y2K) PARABLE There was once a COBOL programmer in the mid to late 1900s. For Several years of this relentless, mind-numbing work had taken its Jack decided to contact a company that specialized in cryogenics. He was put into his cryogenic receptacle, the technicians set the The next thing that Jack saw was an enormous and very modern room Someone who was obviously a spokesperson for the group stepped The spokesman explained that there had been a problem with the Suddenly, a wall-sized projection screen displayed the image of a "That sounds terrific," said Jack. "But, I'm curious. Why is "Well," said the Prime Minister, "The year 10,000 is just around jmr • June 23, 2006 3:14 PM @tc Nice, where'd you find that? You know, I remember thinking about this problem when I was a 17 year old dev, and laughing about how 2038 was going to be much worse than 2000, as I happily compiled my code with 32-bit time quantities. Well, look who's laughing now. David Mery • June 23, 2006 3:24 PM There are many interesting dates; C's time_t failure will happen in January 2038 or 2106 depending if you're using signed or unsigned integers. See "Oh dear! Oh dear! I shall be too late!" ( http://gizmonaut.net/soapflakes/EXE-199707.html ) br -d Woo • June 23, 2006 7:38 PM I still don't get the original problem... Torbjorn Kristoffersen • June 23, 2006 7:46 PM > the format will change and i hope we will be by then 128 bit Um..128 bit? You do realize that while a 32-bit signed integer lasted for approximately 68 years, a 64-bit signed integer will last for 292471208677 years! A 128-bit signed integer will last for 5395141535403007094485264577495 years. Clearly you can see 128-bits would be completely unnecessary as the earth is probably destroyed after 292471208677 years, as well as the sun :) Anonymous • June 23, 2006 8:33 PM > Why should `sleep 1000000000` overflow? No, presumably it works by recording what time it is now, adding the appropriate amount to calculate the time it should wake, then going to sleep until that time. That way it doesn't have to use CPU cycles while it's waiting. But if the calculation of wake-time overflows, watch out. Glenn Willen • June 23, 2006 8:34 PM > Why should `sleep 1000000000` overflow? No, presumably it works by recording what time it is now, adding the appropriate amount to calculate the time it should wake, then going to sleep until that time. That way it doesn't have to use CPU cycles while it's waiting. But if the calculation of wake-time overflows, watch out. Anonymous • June 23, 2006 9:49 PM Dan Bernstein has his own 64 bit Unix time software in the public domain called libtai. another_bruce • June 24, 2006 12:13 AM i always wanted to start the world's first y10k consulting firm. it's only 8000 years away, not too soon to prepare! GSM Weenie • June 25, 2006 3:07 AM I actually hit this bug in 1998... One of our GSM operator customers had a strange setup for their pre-payment cards. Each was valid for one year from date of purchase, but if you bought two at once the incentive for pre-purchasing was that they would be valid for two years. Someone found that the 3rd would be valid for 3 years, and so on... The operator was happy with this - they got more cash up front and didn't mind people buying in advance - after all, they were buying a cash card, not minutes. So if rates went up, no-one lost out. Anyhow, buying 5 in 1998 meant you had valid pre-payment funds until 2003 (or until the funds were used up, whichever happened first). You can see where this is going. Someone bought 40. In 1998, meaning their expiry date was now 2038. When they bought number 41, their expiry date was now 1970 - and the system did not handle it too gracefully. I wasn't involved in the fix, but I suspect it was a combination of checking the expiry date expected was later than the previous one, and limiting the purchases to 5 at once... I hope to be retired by the time it comes up again! Christoph Zurnieden • June 26, 2006 5:39 AM > Why should `sleep 1000000000` overflow? Good question. sleep(1) is bound by Posix to support 2^31 seconds[1]: Because of the restriction of sleep(3): But I must admit: it was nonetheless one of the funnier WTFs ;-) CZ
Erik V. Olson • June 26, 2006 8:41 AM [1] all citations from: "The Open Group Base Specifications Issue 6, IEEE Std 1003.1, 2004". No direkt links, you have to register before, sorry. Oh, good. I've always wondered something. What does false(1) return if it crashes, and is A) a bug, B) a feature and/or C) POSIX compliant? Alex S • June 26, 2006 11:03 AM That's the next generation's problem! I handled my Y2K... let them deal with theirs! *evilgrin* I'll be retired by then! Clive Robinson • June 27, 2006 7:15 AM Folks the bad news is as David Mery pointed out that if your implementation is 32bit signed then 2016 gets you. Well guess what most Unicies have bugs in their time routiens especially those that have POSIX compatability and 2016 is the date that fails most often... IF you hunt around through the internet you will find a copy of Digitals man page for time which actually talks about a roll-over bug in 9999 and the authour obviously had a sense of humour when they wrote it. P.S. For those using Solaris, check the POSIX compatability I was working in a team that discouvered it was not Y2K compliant (with POSIX) but Sun decided that was not a Y2K issue. On speaking to somebody there at the time (who has moved to bigger and better things) they found that it was a known issue (in the source code) that nobody could be bothered to fix... Christoph Zurnieden • June 27, 2006 9:47 AM > Well guess what most Unicies have bugs in their time routiens especially those that have POSIX compatability and 2016 is the date that fails most often... Yes, most unices have bugs in their time routines, but this behaviour is no bug, it's "posixly correct": CZ Sam • June 27, 2006 11:48 AM Haven't seen it mentioned on this thread, and its worth noting: Windows NT (xp, etc) internally use a 64-bit time counter, with an epoch starting in 1600 and counting in 100ns intervals. Most of the win32 time functions use this (e.g. FILETIME/SYSTEMTIME). Christoph Zurnieden • June 27, 2006 1:49 PM > Windows NT (xp, etc) internally use a 64-bit time counter, with an epoch starting in 1600 and counting in 100ns intervals. That's nearly "coordinated universal time" (UTC, see e.g. http://en.wikipedia.org/wiki/UTC for a short summary). The UTC epoch starts at October 15, 1582. Why does the Microsoft epoch differ? Handling time with all those different calenders is a hard job itself, there was absolutly no need to arbitrarily complicate writing portable software further. CZ Terence Davis • June 27, 2006 5:08 PM I have a good one though not Y2K related. I was working for a company that had developed a system with two ways to view system events. First, via the standard Windows NT GUI and the other via a custom written character-mode interface, ala VT-100. During the short window between when daylight saving time starts (or ends) in the US and when it ends/starts in Europe there was a fun bug where the extra hour was subtracted twice. It took me a while to reproduce it and then another while to figure out what was going on (had to look at the Visual C++ runtime source code) and then an eternity to get Microsoft to own-up-to and confirm my findings. Eventual solution was to turn the time into some weird filesystem based time stamp that used 64-bit measures of, I'm not kidding here, pico-seconds since 50,000BC (or something equivalently esoteric). Then convert back to a string. MS said they would address the libc.dll defect in the next release. . .yeah, right. nbk2000 • June 27, 2006 10:02 PM I've just recently been getting spam dated January 18th, 2038. Spammers joke? Or corrupted *nix machine? roger • June 28, 2006 4:19 AM @Ross Patterson: While true, most of the nontrivial, medium- or long-term stuff is now stored in databases, nearly all of which support ANSI date standards (which generally have either a Y10K problem or else no problems for many millennia). @Clive Robinson: That's 2106, not 2016. Going unsigned gives you longer, but means you need 64 bit times in order to understand anything before 1970. @Christoph Zurnieden: It's an ANSI standard. The reason for choosing it as an epoch is that 1600 was a century year that's also a leap year, plus close to the UTC base, or something like that. Rich Painter • July 17, 2006 11:54 AM I wrote on these subjects long ago... The UNIX Time Will Run Out in 2038! [published as "UNIX Time" in Year2000 Will the INTERNET's Network Time Protocol Fail in 2000 or 2036? other unix time-related issue... rich Jeff Silver • December 11, 2007 7:13 AM As there's only a little of 2007 left, I guess this is my last chance to alert people to the "year 2008" bug, which I first thought of shortly after Y2K died down. Even after all the Y2K stuff, there are still systems around that use a 2-digit year (generally with some sort of check so that small numbers are 2000-based while larger ones are 1900-based). Olaf • August 14, 2008 5:43 PM This is kind of strange - I had a problem in cygwin so I tested on a Suse 11 machine also. This happens with any time between 02:00:00 and 02:59:59 on this particular date.
Post a comment
Powered by Movable Type. Photo at top by Geoffrey Stone.
Schneier.com is a personal website. Opinions expressed are not necessarily those of BT. |
|
Comments