Geekerati brace for Unix timestamp milestone In an event that's sure to bring a burst of adrenalin to computer geeks everywhere, the official Unix calendar is about to pass a milestone: exactly 1234567890 seconds since the clock first started ticking. POSIX is the official a widely used time-keeping method for Unix and is measured in the number of seconds that have …
Interestingly, this does not apply to Windows.
Well, for geeky values of interesting.
For the real geeks: The epoch in Windows is 1/1/1601. Windows uses a representation of time which measures nanoseconds since the epoch. This is stored as a 64 bit value.
As anyone who has tried will know, the most popular language for scripting Windows stuff (vbscript) doesn't handle 64 bit arithmetic. So, if you *want* to do date calculations in script, you have to do some really hacky stuff (which is documented).
Anyway. That's your useless bit of information for the day.
"POSIX is the official time-keeping method for Unix"
No, it is not. I never reference (w)iki anything, but:
http://en.wikipedia.org/wiki/POSIX
http://en.wikipedia.org/wiki/UNIX_time
Fairly good overviews on the subjects ... The only reason I even bothered reading the articles is because I just busted a kid for plagiarism when he suddenly became a trifle more eloquent than normal ... Pardon while I dust off my NotEverthingYouReadOnlineIsTrue[tm] (Or "I'm here to teach you to think for yourself, not parrot the words of others") lecture ...
What about the 20-odd leap seconds? When should we and when will we really celebrate the number arrival? I'm worried that we'll all shoot off the fireworks at the wrong moment, you know, like when the rest of the world (Christian and non-Christian) fireworked the sky at the beginning of the last year of the Second Milliennium for some strange reason.
(Paris because of the timing of her fireworks)
All these milestones should be celebrated, like when the trip meter on your aging motor goes through all the 0s.
On my own (W32) box, as I have it use ISO date and time formats (yy-mm-dd), there are numerous files which I have datestamped 01-04-09 at 16:25:36.I didn't have much on when I first realised that was there, but you probably guessed as much.
Mine's the one with the abacus in the pocket.
"Can this thing continue on forever with no tweaking, or will it eventually need an overhaul?"
Nope. Systems that use 32 bit signed integers for timestamps will start to fail in 2038 because signed ints use one bit for sign, leaving 31 bits for data. 2^31 is 2147483648, or approx 68 years.
At the very least, compilers and interpreters will need updating to use more bits for timestamps, and source code will need rewriting to use larger integers. Databases will also need converting to store the larger numbers. Underneath all that, everything from BIOS firmware to OS libraries will need rewriting to take account of the larger ints.
The basic method of adding one to a count every second can last as long as there are seconds to count, of course, but the size of the integer needed to store that info will never decrease, only increase.
As someone born on Midnight of 01/01/1970 I am looking forward to this for other reasons. This counter is personal. And darn freaky to find out about when a junior programmer way back then....
@GottaBeKidding - where did you get that odd 1/1/1601 date? I guess it isn't from C as the point of the time() function is it is the SAME across all OS's. Or, it was when I was a programmer back in the 1990's.
I never used that .NET Framework thing, so maybe it is different in there. Or in some MS application? But the underlying C\C++ codebase uses a proper clock counting from the only important event of the 20th Century... my birth. hehe :D
"It was then noted by a perceptive person that the servers all failed on or before exactly one billion seconds before the end of the Unix epoch in 2038" : http://catless.ncl.ac.uk/Risks/24.34.html#subj3
Y2038 is also a factor for present day financial calculations: a mortgage taken out just five years hence will expire in 2038, and life insurance taken out now is likely to continue well past the end of the 32-bit epoch.
why will it never be negative? Is there suddenly no reason to store past dates? Birthdays for example, or do none of your applications target anyone over 39???
Signed ints are a good idea, and it's what we've got.... If you're making a change (changing signed to unsigned), you might as well do the proper thing and change it to a signed 64bit int (for now). Sure, it's only postponing the problem, but for long enough that it shouldn't be an issue!
C compilers will not need to be modified. The time function is part of the C library, not the compiler.
The time function in the C library returns a time_t. Archaic C libraries often implemented time_t as a signed 32 bit integer. Modern ones use something bigger. Competent C programmers do not make dangerous assumptions about the implemention of time_t, so their source code can work with ancient, modern and future C libraries.
BIOSes do not need to be recompiled. The BIOS works in hours, minutes and seconds (or ticks since midnight). 2^31 seconds since the epoch means nothing to the BIOS.
01/01/1601 comes from the FILETIME structure, which is unique to the Windows API:
http://support.microsoft.com/kb/188768
It can be converted to SYSTEMTIME, which runs from 1601 to 30827. I don't think we need to start worrying about the 30827 bug just yet...
"Pedantry levels are reaching critical, captain. Unleash the hounds."
Actually, the original author of this article (not wanting to be insulting to him personally) demonstates a remarkable lack of IT knowledge for someone writing for an IT site as evidenced by the shocking quantity of bullsh*t therein.
...I am not one to jump to the defense of the Porsche driving journalistic elite, but I think this story is fluffy and inconsequential enough that it doesn't require the rigourous fact checking of, say, a nascent claim of pocket-portable cold fusion or the discovery of Higgs boson in the lint trap of the LHC.
No. There is only one fact here that is of any relevance. Geek Lastday is a little over a week away and any nerdfolk who find their life crystals glowing need to shuffle themselves off to Carousel for "renewal". The rest is just pretty window dressing to keep the readers entertained or, in the case of the easily infuriated, infuriated. This keeps the advertising revenue flooding in in acceptable volumes.
That Porsche doesn't detail itself, you know.
"the underlying C\C++ codebase uses a proper clock counting from the only important event of the 20th Century... my birth. hehe :D""
No, the underlying C codebase uses Windows' own timekeeping schema which is exposed through the native Windows APIs.
This is then translated into UNIX time in the POSIX functions.
...that the very same pathological anal retentives who would be most inclined to celebrate such an anniversary would, in reality, spend the whole event arguing over whether it was, in fact, an event at all.
I predict minor reportage at the fluff-piece end of the news hour, showing lesser geeks partying in the upscale internet cafes of, let me see, New York, Amsterdam and Tokyo.
The coverage will dwell on the one attractive be-croptopped and en-miniskirted female in the room. The male demi-geeks in the background wont realise they are drooling until they see themselves on Tivo later that night.
The report will fade out with a opulently proportioned 30-something gentlemen with a wispy moustacheless goatee and faded WoW T-shirt trying to explain the technical details and how this is almost exactly like that scene in Serenity when...
Ooh! I need to go shave my mo'!
For a start, why are we using a signed integer? It's not going to go into negative time now- and if it did it could only go back 60 odd years.
Get rid of the sign, go for an unsigned integer. Not a huge difference, but allows a well-over 120-year cycle.
Or redefine it as the number of seconds since 19th Jan 2038.
Or go for "number of days since 1st Jan 2000", with the seconds counted since midnight like someone above states that the Bios does already.
To everyone saying that C compilers will have to be fixed, libraries, etc... this has already be done some time ago (at least on LINUX). The system clock IS ALREADY a 64bit value, even on 32bit systems. 32bit systems can perform 64, or ever 128, bit operations after all. Any LINUX system running a 2.6.x is just fine, and any 2.4.x or 2.0.x system is pretty darn old already.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
