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 passed …
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.
Dan, please hand in your geek card...
As every geek worth their salt knows, the 32 bit unix epoch will roll over on January 19, 2038. Any 32 bit unix systems sill running at that time will be digging the flares out of the back of the wardrobe to party like it's 1970!
"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 ...
While the return value is precise to 100ns, it is only updated at each timer tick. Between ticks you have no information. Windows, unlike *Nixes, doesn't interpolate the return value between ticks.
So much for useless information :-)
(just couldn't resist)
"POSIX is the official time-keeping method for Unix ...."
Erm, I'm pretty sure that's not what you meant, so I'll give you the benefit of the doubt. :D
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)
What about the 20/11/2286 bug? Won't anybody think of the children?
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.
This will fail at 03:14:08 UTC on 19 January 2038.
It's potentially worse than the Y2K bug.
http://en.wikipedia.org/wiki/Year_2038_problem
Er, no it isn't. It's a standard which describes many things, one of which is time-keeping; Unix time, a.k.a. POSIX time.
The sun is the same in a relative way, but you're older. Shorter of breath, one day closer to death.
Just made me think of the Floyd. That's all.
"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
There's Unix, and there's Unix, and the 64-bit ones should be fine in 2038. Linux, now, there's another story...
Why the hell would you use a signed number to represent a quantity that will never be negative?
unsigned int a _136_year_clock // me smart!
"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.
Pedantry levels are reaching critical, captain. Unleash the hounds.
where was the word, too busy playing around with del or strike, the UNIX epoch, that is what you should be saying.
And I now notice that wasn't struck out before, POSIX is the Portable Operating System Interface, not too much to do with the 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.
Since a date prior to epoch start is a negative number it looks to me like using a signed int is a good idea.
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...
Unsigned 64 time wraps at some point on December 4, 292,277,026,596. If they start right now and work through the nights, EDS might be able to get the Child Support Agency computers ready.
"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'm no expert on military matters but it seems unlikely that dogs would be handled by a commissioned officer.
...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.
In other words, an IT manager.
Carry on, wayward sons.
http://www.linuxquestions.org/questions/linux-general-1/for-fun-have-a-unix-time-party-700865/#post3432432
That still works, if you set the epoch to 1901-12-13. Doesn't solve the 2038 problem, but at least you don't have the mental hurdle of understanding what negative time means.
Unless, of course the speaker is someone with governmental authority telling a commissioned command officer (Naval Captain) to unleash the dogs of war, which are commonly handled by such officers.
All metaphorically speaking, of course.
http://blog.esync.org/2009/01/things-every-developer-should.html
Paris, 'cause she knows! :)
It'll *never* be 3133731337. Which part of "signed 32-bit integer" don't you get?
No can do mate, signed ints only. :-)
dont effect the end date - they effect the start date. Every time one is added, Jan 1 1970 seems a teeny bit less far away that it really was!
On my linux box, it's declared as a long int, which will be 64 bit if 64 bit compiler flags are set as they often are on 64 bit systems as many are now, and most will be soon.
Well RFC-868 uses 32 bit unsigned but set a epoch of 1900.
So it's gonna run out in 2036, two years before the Unix clock.
So Unix is gonna outlast the the Internet :-)
Everybody knows that the world will end in 2012! It has been foretold and prophesized making this article and all subsequent comments mute and irrelevant.
"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.
So eventually we will replace AC/BC with AP/BP?
...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'!
The comments definitely are not mute.
/pedant
Perhaps you meant: moot ?
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.
I find it hard to believe that anyone will still be using 32 bit systems 29 years hence. Or will be be able to look at them using the virtual reality mode of our posi-tronic brains?
You really shouldnt' quote Wikipedia are as a factual source...
And I really should get my punctuation correct
OS Names + Version/s?
Time & Date?
Whats being done in each case?
Why is there so little fan fair?
AC:
Re-read what I wrote.
mike:
"The comments definitely are not mute."
No? 'sfunny ... I can't hear 'em. Maybe you're running Knoppix 6.0 "ADRIANE "?
This whole forum is a moot court, regardless.
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.
