Slashdot Mirror
Time's Up: 2^30 Seconds Since 1970
An anonymous reader writes: "In Software glitch brings Y2K deja vu, CNET points out a small wave of Y2K-like bugs may soon hit, though it gets the explanation wrong. It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic). Systems that use only 29 bits of a word for unsigned/positive integers, or store time as seconds since 1970 in this format, may roll back to 1970. (Many systems that do not need full 32 bit integers may reserve some bits for other uses, such as boolean flags, or for type information to distinguish integers from booleans and pointers.)"
This is the biggest computer-related time event since Y2K, which begun on January 1, 19100!
And which systems are those?
Any of the common architectures use 29 bits instead of 31?
--
Use Vobbo for Video Blogs
SOCIETY AS WE KNOW IT WILL COLLAPSE!!!! I have to get bottled water and batteries ready! This will be a complete disaster--just like Y2K!
Oops!
y2.003k?
...Run for the hills!
find / -name "*.sig" | xargs rm
My two-bit computer ran out of time the moment it was turned on...
From excellent karma to terible karma with a single +5 funny post...
This seems interesting, but what systems do not use the FULL 32 bits to sore these numbers?
I would bet that if those systems did malfunction because of this, it would not do tons of harm - and upgrading wouldn't cost a cent.
With some of the fashion's today (bell bottems, et al.)
this has been a problem since 1970. is it news that c-net realizes it?
The bug effects older unix systems. So if your still using UnixWare, you may be in trouble.
Hi there
Until, what, 2032, when the 32 bit unix timestamp hits the wall.
I could of course be wrong but I'm pretty sure there aren't 31-bit architectures. At least, these architectures are exceedingly rare if they do indeed exist.
What I believe this article is referring to is that some software may have been coded to use a bit in integers to store extra info. This seems like a pretty bad idea though as it would have all sorts of interesting effects on overflow and such. It would seem like it would only be useful to a very very very tiny portion of software since the overhead in using this method as a general purpose solution would be terribly difficult.
Sounds like it's just the story of yet another software bug...
int func(int a);
func((b += 3, b));
If 1K = 1024 then Y2K is 2048. We still have a ways to go on that one! :)
...is 2.6 affected by the bug??
The IT section color scheme sucks.
"Many systems that do not need full 32 bit integers may reserve some bits for other uses..."
NOT!
There are stories, there are non-stories, and finally, there are Slashdot stories.
This time I'll know all the answers on those darned school tests.
perl -e 'print "seconds left: ", ((2**30) - time), "\n"'
Sex - Find It
I was born just before 1970.
I'm a billion seconds old.
Holy shit.
How many of you programmers are storing your years using 4 digits? Yeah, that's what I thought, all of you. What happens when it's January 1, 10000? Hmmm? Yes, that's right, your software will fail. It will roll back to 0, which wasn't even a year!
Now, I know what you're thinking. "There's no way someone will be using software I'm writing 8000 years from now." Yeah, and that's what programmers said 30 years ago about the year 2000. Be smart, and play it safe. Use a 5, or better yet, 10 digit year. What's a few bytes?
IIRC, bugger all went wrong. No nuclear weapons randomly fired off in any direction, no computers melted (well, none of mine)
There was no reply, though. His computer probably thought my letter was from a century ago.
The program in question was revised in 1997. Most companies already had kicked off their Y2K programs by then. The popular press was already starting to run end of the world warnings. OK, so it wasn't a Y2K problem as such, but how this company managed to ignore the problem at that time is truly baffling.
So this is why John Titor traveled back in time!
John Titor
in mainframes and other "big iron" in finance shops.
Okay -- I did the math, and 2^29 seconds since January 1st 1970 would have been up on January 4th, 1987.
2^30 seconds since the epoch puts us into January 9th, 2004.
Yaz.
They've got about 19 days by my system clock.
jonathan@perl:~/dev/interface/lib$ perl -le 'print time();'
1072051517
jonathan@perl:~/dev/interface/lib$ perl -le 'print 2 ** 30;'
1073741824
jonathan@perl:~/dev/interface/lib$ perl -le 'print 2 ** 30 - time();'
1690288
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60;'
28171.4666666667
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60 / 60;'
469.524444444444
jonathan@perl:~/dev/interface/lib$ perl -le 'print 1690288 / 60 / 60 / 24;'
19.5635185185185
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
Its epoch is midnight 01-Jan-1904 and it uses an unsigned 32-bit integer to count seconds since then. That means it will run out at 06:28:15 09-Feb-2040.
:P
But, I'm sure Apple will have released a new Newton by then!
(I don't suppose anyone's ported the Rosetta writing recognition system to other PDA's, just in case?)
I saw one minor problem with time()==10^9 where some logging put the time_t in a 9-digit area. That rollover happened in 2001.
The 2**30 rollover in January strikes me as pretty unlikely to affect much. Are there any commonly used 31-bit archs? (I think IBM s390 is but only for addressing, not data - please correct me if I'm wrong) In 18 years of working on UNIX software I don't think I've ever seen code to "cleverly" re-use the high bits on a time_t variable for something else.
Oh well, back to waiting for 2038. I should be retired by then, have fun kids!
I plenty left over from Y2K. For those who did not prepare for Y2K and laughed at all the suckers who stockpiled and hid in bunkers, Ha! I will finally have the last laugh! - going into my bunker now....
From excellent karma to terible karma with a single +5 funny post...
Could you be any MORE confusing? 2^30 is not 1 billion. It's 1,073,741,824. And the date as of right now is:
$ date +%s
1072051722
So, yes, there is an issue with the date overflowing a 30 bit space. I'd hardly say it's relevant, any software that made such a braindead choice (why 30 and not 32 bits?) deserves to break. But it has nothing to do with a billion or anything else related to base 10. It hit 1 billion a long time ago, and it was covered then.
that time should be stored as self-describing format, such as:
header containing:
2-bits (E) for # of bits for Epoch
1-bit for whether the time is a floating point format
if not floating, then:
2-bits (N) for # of bits for the time
2-bits (n) for # of bits for the resolution (1/2^n) (e.g. n=8 would mean 1/256 second resolution)
if floating, then follow some IEEE standard representation.
I hold it, that a little rebellion, now and then, is a good thing. -- Thomas Jefferson
Possibly use this information for? as far as i understand, this only affects very old systems, and you oughta be just a little up to date!
i once read that UNIX would get troubles around 2038?
*resistance is futile, or fuzzy, i dunno*
It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic).
My arithmetic says that 1 billion = 1,000,000,000 whereas 2^30 is 1,073,741,824.
The 1 billion rollover happened back in September 2001. The 2^30 rollover is in a few weeks time.
A different, but related problem:
It was a while ago when we hit one billion seconds. There was some concern that this would cause bugs in programs that printed the time in seconds using only nine digits. Much like Y2K, I don't remember anyone talking about it afterwords as having caused real problems.
Hey isn't this another opportunity for outrageous consultants fees and inflated IT salaries? Imagine the repercussions if your CEO got stuck in the lift 'cause of a 29 bit integer. Not to mention all the Java toasters out there that'll need upgrading. Get out there and start billing!
I'm bracing for the 2034 Y2K (or is it Y2KATF) bug, the one that'll overflow the Unix time() function.
...
You think I'm trying to be funny ? well let's see : people were worried that systems built in the 80s and before would display the 99 Cobol date bug, and/or the 2-digit date bug in 2000. 1980 and before is 20+ years ago, and there weren't that many computers/microcontroller around during those 20 years compared to what's to come, and operating systems weren't very unified. Today in 2004, we have kajillions of Unix machines around : how much do you bet a lot of these will still be running 30 years from now ?
This said, I'm not bracing quite yet to tell the truth
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
For the less insane amongst us:
> perl -le 'print ((2 ** 30 - time()) / 60 / 60 / 24);';
19.5553587962963
"our systems only have a Y2K bug every few thousand years!"
-- 'The' Lord and Master Bitman On High, Master Of All
2^30 = 1073741824s ~= 34y 9d 97m
1970JAN01 0000hr + (34y 9d 97m) ~= 2004JAN10 0137hr
January 10th should be an interesting day for somebody.
[You have a stable society when some nut guns down a schoolyard and the law doesn't change.]
I've seen some comments about hey, another Y2K waste of time... blah blah blah. But think of it this way:
1 - What if all the money that was spent to "fix" the Y2K bug actually fixed the bug.
2 - Most people say that all the money spent "fixing" the Y2K bug was a waste because nothing happened.
3 - How many people have insurance of some sort, and have never needed it (I am). Yet every year, you renew your policies.
There are two things we can do about these "time" bombs. The first is to do nothing and hope that all is well. Or we could audit the code that may fail. A bit like paying insurance.
[ PS: it is SCO's code, so they should pay ]
it is only after a long journey that you know the strength of the horse.
I'd better go stock up on water again in case everything falls apart then...
I couldn't think of a sig.
More probably there will be problems with bit arithmetics like time 1 or something.
Seriously, could we please get started fixing this 2038 bug now? I don't know if it's practical to change time_t to "long long"; if not, could we at least officially define the successor to time_t?
I know that the emergence of 64-bit chips will alleviate this somewhat, but it wouldn't surprise me if at least embedded systems are still running 32-bits in 2038.
I know that "long long" is common, but it's not part of the official C++ standard yet. Shouldn't we be putting this in the standard now? It's not too much to require language libraries to have 64-bit integer support (if necessary). This doesn't have to be painful.
I'll feel a lot better the day that I know what I'm officially supposed to use instead of time_t -- or if I can be given a guarantee that time_t will be upgraded to 64 bits within the next few years.
Can you roll over?
Infuriate left and right
Alternative headline:
PTC Steals Christmas for many in IT.
Parametric Technologies has this problem. Seems they were trying to insert the year 2038 bug into their code, but the messed up and got the year 2004 bug instead.
One of the headlines on the news.com.com home page is "Lost? Hiding? Your sell phone is keeping tabs."
If CNet doesn't even correct glaring spelling errors, how can anyone expect anything reliable from it?
Get off my launchpad!
It seems like we will probably all be using 64bit computing by 2038 which will fix the problem itself. By then we won't have to worry for at least a few thousand years (I think).
http://maul.deepsky.com/%7Emerovech/2038.html
antitux@TuX0r:~$ perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
antitux@TuX0r:~$
hrm..
Looks like we're fucked too.
Nah, why take away the thrill and jobs of our childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,childrens, childrens,childrens,childrens,childrens,children?
[daleg@lithium]~>perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
[daleg@lithium]~>uname -rs
SunOS 5.8
Interesting, it stays at the limit rather than rolling over.
So does this mean we can sue SCO if our systems crash?
These might be a problem for many slashdot readers down the road, I for one plan on being likely dead, what with being old fart already. So here's those "overflow" dates, mm/dd/yyyy U.S.A. format:
02/06/2036 - systems which use unsigned 32-bit seconds since 01/01/1900
01/01/2037 - NTP time rolls over
01/19/2038 - Unix 32 bit time, signed 32 bit seconds (that's to say, 2^31) since 01/01/1970
02/06/2040 - Older Macintosh
09/17/2042 - IBM 370 family mainframe time ends, 2^32 "update intervals, a kind of 'long second'" since 01/01/1900
01/01/2044 - MS DOS clock overflows, 2^6 years since 01/01/1980
01/01/2046 - Amiga time overflows
01/01/2100 - many PC BIOS become useless
11/28/4338 - ANSI 85 COBOL date overflow, 10^6 days since epoch of 01/01/1601
and my personal favorite,
07/31/31086 - DEC VMS time overflows
maybe a midlife crisis is just our internal clocks rolling over.
The thing to remember is that "Y2K Program" doesn't neccessarily mean "fix the software". For example, one of the computer systems used for air traffic control in Canada is not Y2K-compliant. Rather than fixing the bug (which could have introduced more errors than were solved), the engineers looked at how the date was being used and what mitigation strategies could be applied. In the end, they determined that the simple solution was to change the clock back by exactly 24 years, as 1976 would match 2000 in both day-of-week and leap-year calculations. That computer is still running under the delusion that it's currently December 1979. In the end nobody cares that it's not Y2K compliant because we don't keep data for 24 years and therefore the erroneous date can never lead to confusion between current and historical data.
Who cares about C++? Blech!
"long long" is in the C standard (ISO/IEC 9899:1999(E)), but it's much better to use int64_t or uint64_t, which are also defined in the standard ().
2038 will be a big mess.
For the first programming job I had (at an insurance agency) they were using 9/9/99 as infinity. So, if your benefits mysteriously stopped a few years ago...hey, it wasn't my fault!
The most interesting time related bug I came across was with a RDBMS called Advanced Revelation. The program counted days from 1/1/1970. In May 1997 the sequence counter went from 4 to 5 digits. It was interesting, the database was stable, but there were quite a few reports and add ons that were designed to expect a 4 digit number.
BTW, I built a 3/3/3333 into a program that I wrote for a company.
Less is more !
Wish I knew COBOL better than I do... I'd be rich! ;)
There was once a COBOL programmer in the mid to late 1990s. He became a private consultant specializing in Year 2000 conversions. He was working 70 and 80 and even 90 hour weeks and travelled through 20 different countries, but it was worth it.
Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. He must have suffered some sort of breakdown. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was very expensive process and totally automated. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life.
He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "It is over?" he asked. "Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?"
The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn't get excited; someone important wanted to speak to him.
Suddenly a wall-sized projection screen displayed the image of a man that remarcably looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.
"That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in *me*?"
"Well," said the Prime Minister. "The year 10000 is just around the corner, and it says in your files that you know COBOL...."
If you read the Cnet artlcle, this only affects software from a single company, and they are supposed to be "product lifecycle management" specialists. Why would anyone else care? The rest of us have until 2038 before there is a problem. Probably will get fixed in the 4.2 kernel.
leave bits and bytes to assembly kernel/driver programming and to compiler programmers. Normal application programmer should work with symbols.
So would an entire game graphics engine be considered a "driver" under your taxonomy?
Besides, with 10GHz 8xCPU 64GB-RAM typical home computers who cares
Multimedia apps will still need every cycle they can get to make a more immersive projection of reality onto a display, no? Radiosity lighting and Monte Carlo raytracing still cost cycles.
$ ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
$ uname -rs
IRIX64 6.5
$ perl -v
This is perl, v5.6.1 built for irix-n32
Copyright 1987-2001, Larry Wall
http://maul.deepsky.com/~merovech/2038.html
mikebabu% perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
-- "At Microsoft, quality is job 1.1" -- PC Magazine, Nov. 1994
Perhaps all time counters should be bignums?
Bad idea. A "system to contain radioactive wastes" will usually be an embedded system with a fixed memory. Fixed-memory machines need fixed-size data structures, and a 64-bit count of seconds should hold even over lifetime-of-the-Universe or lifetime-of-copyright time scales.
$ ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:08 2038
Tue Jan 19 03:14:09 2038
Tue Jan 19 03:14:10 2038
$ uname -mrs
Linux 2.4.9-40smp alpha
$ perl -v
This is perl, v5.6.0 built for alpha-linux
Copyright 1987-2000, Larry Wall
I use Pro/Engineer on a daily basis, and the problem has been blown out of proportion for the majority of users. Unless you use some of the more exotic modules PTC offers, it's not a problem.
BTW, Pro/Wildfire rocks on Linux!
"It's such a simple flaw; we don't believe it requires extensive testing to deploy the patches," he [PTC spokesman Joe Gavaghan] said.
That's an excellent plan! Nothing bad has ever come from that train of thought before.
In future news, PTC spokesman Joe Gavaghan is now working for Microsoft's Security division.
Nooooooo!!
If we use Plank-Time and 256bit integers, we can handle 1.981384141637854Year*E+26. We should handle time as 256bit integer based on placktime and convert to local human time-standards as needed. We should support for a second 256bit imaginary integer and conversion to two floating point-math-units (one real and one imaginary) because some calculations in Physics involving time occur on the complex plain. I propose that zero-time be zero Julian Date.
Impeach Bush
> Who cares about C++? Blech!
Yeah, that's a helpful attitude.
C++ has a huge influence on other languages. Just to take one tiny example (of many), note that PHP inherits its time() function from directly from C/C++, and so it also inherits the same signed 32-bit limitation. Once C++ gets upgraded, then many other languages will follow.
> "long long" is in the C standard
The point is that time() still returns a 32-bit value in both C and C++. That's the problem we're trying to solve here.
In case you haven't figured out, we are now a reactive society as opposed to proactive. We fix things, or usually replace them, when they break, not before. Americans don't think much about the future beyond what's on television later that day.
Yes, we could fix the bug now. Likewise, we could also address world hunger, the deficit, the exploding crime problem, terrorism and a host of other issues with such cautious, preventative measures, but doing so wouldn't give us the instant gratification we desire now, so we'll let your children deal with the deficit, crime, terrorism, poverty, hunger and the time bug. We have better things to do. I'd write more, but I think "Friends" is coming on.
time() doesn't return a 32-bit value, it returns a time_t. The nature of a time_t is is implementation dependent.
I kid you not, I'm not sure when, but my iBook rolled back to 1970. I was copying a document from it, noticed, and wondered if it has been the battery dying or something. I'm glad this cleared up, but I'm not sure why my laptop jumped the gun. :)
By reading this you acknowledge that you have read it.
The point is that time() still returns a 32-bit value in both C and C++. That's the problem we're trying to solve here.
No, time() returns a time_t value. The C standard defines time_t as an arithmetic type capable of representing times; there's nothing in the standard that says it has to be 32 bits, or that it counts seconds from 1970-01-01, or even that it counts seconds. (I think POSIX imposes some more specific requirements, but it still allows a 64-bit type.)
I've worked on several systems that already use a 64-bit type for time_t. I suspect that all systems will do so well before 2038.
If the problem hasn't taken care of itself in 20 or 30 years, then we can start worrying about it.
(Switching to an unsigned 32-bit type would buy us another 68 years, but it would make it impossible to represent dates before 1970.)
You expect to have twenty generations of descendents by 2034? Ooh ooh I got it! You're from Alabama, right?
mogorific carpentry experiments
-- Who cares about C++? Blech!
So in your little corner of the universe, which language is everybody supposed to care about above all others? Let me guess. Perl? Java?
Please enlighten us with your wisdom.
And dismissing the whole C++ language with a flick of the pinky is modded up to 2 ???
***SIGH***
Yes, there are Unix versions for them, but it's unlikely that many of them have hacked their date-bits usage to cause problems now, as opposed to waiting till 2038 to get in trouble.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
> I've worked on several systems that already use a 64-bit type for time_t.
That's nice, but it's not good enough.
I should have said that in many implementations of C and C++, time() still returns a 32-bit value.
You are correct when you say that it can return 64-bits. But the problem is that it's not required to do so. The problem's not fixed until time_t (or its successor) is required to represent dates after 2038.
Sorry about the misstatement and thanks for pointing out my error.
You mean, "If time_t were unsigned". Read up on the subjunctive mode.
If you want to know what the real values are, this article and the one on cnet is wrong in so many ways... ugh, but here are the real ones that will really affect people:
:)
FreeBSD 2.2.7 will start having this clock problem on January 18th, 2038 at 20:14 (8:14PM) EST when the unix clock on FreeBSD will read: 2147483640,
20:15 (8:15PM) EST will cause FreeBSDs clock timer to claim an invalid date... joy !
That's not 2^30 folks, that's 2^31 (2147483648) or about 8 seconds after the time I quoted above.
I know because we still have one box running 2.2.7 here (and what a fun box it is too!) can't handle more than 128megs of ram. What is this - the dark ages? that was rhetorical...
Of course 64-bit time_t's will theoretically fix all that... that is, until we design computing systems intended to survive the death and hypothetical rebirth of our universe...
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Excuse me while I go make sure my Javascript that counts down until the end of the world is up to snuff.
[/sarcasm]
Ignoranus: A person who is both stupid and an asshole.
The KDE newsreader Knode stored and sorted timestamps as a string, so messages after the rollover (1xxxxxxxxx) were sorted before messages before the rollover (9xxxxxxxx). It was fixed fairly quickly.
I shorted A31 to ground with a screwdriver on my Motorola MC68060 board. It blew a pullup resistor on an open collector output driver. Now A31 is always low -- and I'm too lazy to replace the tiny little 100 ohm surface mount. It runs just fine as long as I don't address high memory.
I just want to know: Does that count?
"the exploding crime problem"
I don't know where you are, but in the U.S. crime rates, especially violent crime, have been going down for the last 10 years. You wouldn't know it from watching the news, though.
would it be so bad for us to all just pretend it's the 70s again?? it might be fun.
There's your sign....
Tell me when the apocalypse is over.
John Titor. Do a google search on him. Pretty interesting, and not completely unrealated.
sh-2.05b$ ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
sh-2.05b$ uname -rs
Darwin 7.2.0
sh-2.05b$ perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
Sticks at the limit here too.
-Don.
Cwm, fjord-bank glyphs vext quiz
It's not storing as text that kills big databases, its the lack of indexing.
This is my sig.
There can't exist a binary system with a 29 or 31 bit word. Given the nature of binary, you can have words based on multiples of 8 bits (and sometimes 4 bits such as a nibble (4 consecutive bits)). You may be thinking of when you are counting the registers in a CPU or the columns in a memory where you would start with %r0 and go to %r31 plus the extra registers in an ARC CPU for example.
Just thought I'd help you clarify a few things.
It's in mid 2005 right now. And I set it to the correct time last week. Stupid taiwaneese motherboards.
True genius is grasping a situation like a peice of fruit, and peircing it just right so that it drains dry.
Its interesting, how no one considered this would happen eventually and just started to use 64 bit ints to store this from the long run.
Well, considering how it was the 70s, the change of the millennium seemed ages away, 32 bit seemed a *lot* of memory back in those days. Think a small database with 64 vs 32 bit timestamps. My dad used to work in IBM way back, and I remember he's told me about a printing company which turned down getting another mb of mainframe memory from them, because it'd cost them $150,000. That's 50 cents extra per date.
If I remember my history right, it was one of the Apple developers that in the design process cut two digits from the year, in order to save memory. Since they were trying to make a consumer product (or at least consumer-priced product), even more work went into minimizing cost. This was also in the 70s. The IBM PC just copied that system.
Today, it seems utterly stupid to not double it. Just understand that today the machines have literally thousands of times more RAM than they used to. It was a real scarce resource, where every bit counted. Nobody was thinking of year 2038, they were thinking of how this would improve performance right here and now. Also at the time, computers were mostly big mainframes, with pretty much specialists and geeks. So they probably thought it'd be easy to fix when the issue arised.
That they were mostly unable to foresee the explosion of a) the personal computer, b) the Internet and c) embedded electronics before the end of the millenium, is hardly anything you can blame them for. It wasn't really until near the very end of the millennium that people really understood the magnitude of the task. That's why the y2k-problem became such a big thing, if it had been some mainframes in a computer lab somewhere, noone would have lifted an eyebrow. It was that "the computers are everywhere, in all offices, they'll all go to hell, and society will collapse" which made it big. At which point it was a little late to fix the underlying format, since so much code relied on it being of that type.
So if there was a time, it'd have to be the middle time... after memory got "cheap", before too much code started to rely on it. It's hard to say if such a period even existed. And even if it did, I'm sure 99,9% of the people would have wondered why the fsck you need to fix that issue NOW. The old system works, and will work for many years yet (like, long past the life time of this PC. We can fix it in the next one). Don't knock it if it works, right? So I find it quite natural it turned out the way it did, no matter how smart people were.
Kjella
Live today, because you never know what tomorrow brings
unless you hire ME! CNET said so.
The Kruger Dunning explains most post on
It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic).
It's not a billion seconds, it's 1,073,741,824 seconds -- right?
and we are close:
perl -e "print time();"
1072061932
1 365 day year is 60*60*24*365 = 31,536,000
seconds.
there are 8 leap years in there, and probably a few leap seconds, sure, but:
1,000,000,000 / 31,536,000 = 31.70979 years to hit 1 billion seconds.
1970 + 31.7 years puts us in September 2001. Randall Schwartz called this event U1E9 (unsigned 10 to the 9th power?) - there were a few glitches (mostly sorting related), but I've still got all my canned goods and batteries.
who's moderating the meta-moderators?
A girl once told me she wouldn't go out with me until the end of time.
Sally Roberts, pucker up.
"Why Subscribe?" Good question...
Actually UNIX is really using an effective 31 bits because of the fact that it defaults to a signed quantity, and hence the highest order bit is really a sign bit. So when the clock finally increments 0x7FFFFFFF (19 January 2038 03:14:07) to 0x80000000 the time will wrap back to 2,147,483,648 seconds before 1970, e.g. instead of being Tuesday 19 January 2038 03:14:08, it suddenly becomes Friday the Thirteenth (specifically Friday 13 December 1901 20:45:52).
Those systems that are using an unsigned 32 bit time value can go on until Sunday 7 February 2106 06:28:15.
If we were to switch to 64 bits, we could use a resolution of nanoseconds with all that extra space and still represent time until Friday 11 April 2262 23:47:16.854775807 before the sign bit becomes an issue (and negative values can represent time back to Tuesday 21 September 1677 00:12:43.145224192).
now we need to go OSS in diesel cars
And when all the stupid computers which represent numbers in 30 bits catch fire and explode when the numbers overflow (just like y2k, remember when all the banks went crazy as their unpatched computers exploded and the software maintainers suddenly had thousands more dollars appear in their bank accounts by accident), we can all laugh that much harder about how many bits they used to store a number.
Wow, I opened that in a background tab in Firebird, figuring I'd get a chuckle when I was done with Slashdot.
Then about ten minutes later I notice the scrolling status bar on my Slashdot tab:
Are YOU prepared for an emergency? How about for Y2K?
My first though was that someone had brilliantly hacked the comment system to include javascript... then I remembered the Firebird "feature."
This Like That - fun with words!
watch -n1 'python -c "import time;print hex(int(time.time()))"'
A 32-bit patch to a 16-bit interface running on top of an 8-bit OS written for a 4-bit microprocessor by a 2-bit company that can't stand one bit of competition.
In standard /. fashion, I will overlook factual inaccuracies in the interest of pursuing my goal of correcting everyone's grammar. As such, I must tell you that Y2K *began* on January 1, 19100.
-Looking for a job as a materials chemist or multivariat
When you could only rent your phone from Ma Bell
And it had to be pluged into the wall
and it didn't have any buttons for dialing.
And the grocery stores still had tube testers.
And the TVs had 'knobs', and 7 channels.
And every place was filled with cigerette smoke.
The pollution in LA was twice as bad as it is now.
And some jerk made a movie that has me afraid of sharks to this very day.
OTOH,
Man was landing on the moon, gas was less then a buck, and he romones where just getting going.
DnD was giving nerds something to do between poundings at school, and Star wars told everybody Sci.fi didn't have to be cheesy.
I rode my first wave, had my first kiss, and learned never, ever, EVER, give cheese cake to a dog.
The Kruger Dunning explains most post on
I Need a Binary Clock so I can watch it turn over on Jan. 10.
Any suggestions?
Since January 1, 1970 At 00:00:00, 30 bits worth of seconds brings us to January 9, 2004 1:37:04 AM. OOOOhhhh. Am I supposed to worry, or should I concern myself with replacing my 32 bit computer within another 34 years, 9 days, 1 hour, 37 minutes and 4 seconds (when the 31'st bit flips), or should I *really* worry in 68 years, 18 days, 3 hours and 14 minutes when the last bit flips (assuming unsigned integer)?
ICQ clients used to crash instantly if you set your clock past 2038.
Well, someone check their kernel source to see if SCO is going to flake out... ...we are apparently in possession of their sources, after all :)
Jeremy
Firstly, every so often a leap second is added to UTC. For this reason, over timescales of years it is impossible to exactly map unix time_t and calendar times.
Another issue is determining when a transaction happened that occurred across multiple time zones...
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
> I think it'd be much nicer if the language could handle Perl-style returning of arrays.
/* waif, indeed! */ /* no jogging allowed */ /* guiness record */ /* doorway limitation */
/* name of girl */ /* diameter of waist */ /* diameter of chest at most interesting offset */ /* measure are the hips, don't get distracted, you naughty tailor */ /* it's good to hold on to! */ /* if they can't see it, they can't suck it */
The guy who posted above you 8 minutes earlier already understood the solution: return a damned pointer!
Why, oh why, is this so hard to understand? Here, I will provide a contrived, stupid example.
#define MIN_CHEST 25
#define MAX_CHEST 55
#define MIN_WAIST 19
#define MAX_WAIST 65
typedef enum { brown, blue, red, blonde, blue, cmax } colour_t;
typedef struct
{
char *name;
size_t waist;
size_t chest;
size_t hips;
colour_t hair;
colour_t eyes;
} girl_t;
typedef struct
{
size_t count;
girl_t *girls;
} girl_array_t;
void mempanic()
{
write(STDOUT_FILENO, "oh oh\n", 6);
_exit(1);
}
girl_t *createAllGirls()
{
girl_array_t *girlArr = calloc(sizeof(*girlArr), 1);
char name[64];
size_t waist, chest, hips;
colour_t hair, eyes;
if (!girlArr)
mempanic();
for (waist = MIN_WAIST; waist girls = realloc(girlArr->girls, sizeof(*(girlArr->girls)) * (girlArr->count + 1));
if (!girlArr->girls)
mempanic();
sprintf(name, "chick #%i", girlArr->count + 1);
girlArr->girls[girlArr->count].waist = waist;
girlArr->girls[girlArr->count].chest = chest;
girlArr->girls[girlArr->count].hips = hips;
girlArr->girls[girlArr->count].eyes = eyes;
girlArr->girls[girlArr->count].hair = hair;
girlArray->count++
}
return girlArray;
}
There. Everything you need. A single return value, a dynamic sized array of structs. And girls.
Of course, I didn't test it. But if you really need girls that bad, let me know and I'll make sure it builds.
Now, this is just some text to avoid the lameness filter. Doo dah. Tobacco use during pregnancy increases the risk of preterm birth. abies born preterm are at an increased risk of infant death, illness and disability. Health Canada.
L'usage du tabac pendant la grossesse accroit le risque d'un accouchement premature. Les bebes prematures font face a des risques plus grands de mort infantile, de maladies et d'incapacites. Sante Canada.
Okay. Maybe I'll de-indent my code. Stupid piece of shit.Meta-control-Q should fix that.. Oh great! Now I need more characters per line. Comments, here I come...
Do daemons dream of electric sleep()?
> ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
> uname -sr
FreeBSD 4.6.2-RELEASE-p23
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Both use signed integers! They must have a common heritage. It's called the POSIX spec.
Next, they'll accuse Linux of plagurizing the six lines of "return -EFAULT" that occur in kernel/time.c of the 2.4.22 kernel because they are so similar to a few "return -1" lines of SCO's UNIX93-compliant pride and joy.
If anyone is starting a pool for the end of the world, put me down for Tue, 19 Jan 2038 03:14:07.
You can't judge a book by the way it wears its hair.
Integers are represented exactly in IEEE floating point as long as they do not exceed the size of the mantissa. Many systems do not provide 64-bit integers. The trick is to use the correct base unit. For time, I've often used elapsed microseconds since the epoch. For money, you can use cents or millicents, depending on how you want to round things.
Mea navis aericumbens anguillis abundat
Hope I get an update before 2038....
[ryan][~][15:152B][0] perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
[ryan][~][15:152B][0] uname -rs
Darwin 7.2.0
Cthulhu loves you.
"Effect" the verb means "to cause".
For example: "The effect affected him such that it effected his defection from his affection toward her defective affectation for reflective detective stories".
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
It just stays at the limit on 2.4.21 with perl 5.8. The expression at the bottom properly rolls back though. Any idea of why the parent is rolling back to 1901? Shouldn't it roll back to 1970?
% perl 2038.perl.txt
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
% uname -a
Linux Hertz 2.4.21-xfs #1 Mon Sep 1 17:17:44 CEST 2003 ppc GNU/Linux
% perl -v
This is perl, v5.8.0 built for powerpc-linux-thread-multi
[...]
% perl -e 'print scalar gmtime 1e10, "\n"'
Wed Dec 31 23:59:59 1969
Trollem mirabilem hanc subnotationis exigiutas non caperet
Didn't we just begin the fourth age a few days ago? We should have awhile.
You're dumb.
"The effect affected him such that it effected his defection from his affection toward her defective affectation for reflective detective stories".
The period goes before the end quotation, you dumbass!
UTC is a mess. I'd rather see all computer clocks use TAI (International Atomic Time) internally.
Mea navis aericumbens anguillis abundat
The Y2K preparedness team at my company went crazy over the hype. They set up a big "Y2K Command Center" (commandeered a big teleconferencing room) with PCs full of nothing but Excel spreadsheets with all the functionality metrics for our whole enterprise painstakingly listed. Every ten minutes, all of us in the trenches were supposed to telephone this "command center" so they could update their spreadsheets (yes, web site "foobar" is still responding, yes, this database still works.)
About 30 minutes before Y2K hit our time zone, I noticed the maintenance guys firing up the big diesel backup generators in our rear parking lot. I asked my boss about it. "Oh yeah," he said, "They're going to take us off the power grid just in case." No big deal to us: we have UPS's on all our PCs, and the power fails over all the time in the always-spectacular Kentucky summer thunderstorm season. (Half of the building's lighting turns off to conserve power, everyone slightly gasps, but keeps working...we're used to it.)
But not so for the "Y2K Command Center." The "suits" had plugged all their spreadsheet-running PCs straight into the wall, and when we changed over to the generators (on their command) the momentary power drop caused *every single one* of their machines to go down....
We laughed in their faces openly. If that's not being hoist by one's own petard I don't know what is. It almost made it worth it not to be kissing my sweetie on New Year's Eve.
I can see it now:
Company: We need to get these bugs fixed in short order.
me: Go screw. Why don't you go outsource the bug fixes to India?
The new Millinium began Jan. 1, 2001. The year 2000 mearly ended the second millinum.
The music is all around us. I can hear it. Can you?
Not to be too pedantic or anything, but to use your shift right scheme for extracting integers, the second-to-LSB must be zero (naught) for even numbers, and 1 for odd numbers (in a two's comp machine).
So the tag bits have to be 00 or 01 for even integers and 10 or 11 for odd integers.
Some implementations of LISP go even further, using additional bits in the non-integer case.
For example:
0 - Upper 31 bits are signed integer (even or odd).
001 - Mask to get pointer to object, 8-byte aligned.
011 - Upper 29 bits are index into cons table.
101 - Upper 29 bits are index into string table.
111 - etc.
I seem to recall that Scheme, a LISP dialect, uses this type of tortuous mechanism to extreme extent.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
Maybe this is what the Orange Alert is about.....
If you have BSD's date instead of GNU's then try:
$ date -u -r $((1 30))
Sat Jan 10 13:37:04 GMT 2004
I think this happened to the Vegas.com sports betting lines page. Only thing is that that page has been like that for several days. *shrug*
Later,
Patrick
Odd that you mention terrorism. On Y2K, police uncovered a plot to blow up space needle. Similar incidents were feared around NYC Times Square, and other high profile locations.
And everybody knows what happened two days after the rollover to 1000000000 seconds.
And even, right now, terror threat level is at its highest since second 1000215900...
Time runs out. H-Bomb crap released or something. Orange alert level.
;[ Teh end :(
It's totally terrorist related
_________ Help me get a PSP!
Some filesystem standards include a field for location as well as date and time; usually this is the offset from GMT. Even in today's macroscopic time terms this is a useful way to keep track of when a file was *actually* created or modified.
If you are going to be keeping track of time down to the plank scale, wouldn't you also need to keep track of location for that precision to mean much?
G. G. Surdu
Global Year 2000 Program Manager
Ford Motor Company
If he's a manager, there must have been other people he was managing. That makes about a dozen people, globally, worrying about a microprocessor THAT DOESN'T EVEN SUPPORT CALENDAR FUNCTIONS. You might as well be the Global Year 2000 Program Manager for bottled water... So, I bet if you look up that guys resume, he left no trace of this stint!!
Cover your eyes and click this link!
Actually, there are approximately 86,400.002 seconds in a day (see here). In addition, you neglected to add the leap seconds that may or may not be required.
I'm just sayin', if you're going to try and be ultra accurate, then don't half-ass it.
I've heard some lofty goals, but this goes to a whole new level.
I think you mean:
I've heard some lofty goals, but this goes to a whole 'nother level.
^-^
No, let's not - I'm planning to spend the last couple of years before I retire making silly money fixing old C/C++ programs to work with longer time_t . It's my pension dammit!
Dude, everyone knows that the Martians were wiped out by Dr Moreau's anthrax-based hybrid virus. Oh, sure, all the Martians officially died of "the common cold", and all those Londoners officially died of Martians, but who are you going to believe, the British or your latest edition of the "League of Extraordinary Gentlemen" penny-dreadful picturebook?
--grendel drago
Laws do not persuade just because they threaten. --Seneca
C++ does have some good features buried in the morass (mostly features copied from Ada, and sometimes given new names), but it still inherits all of the weaknesses of C.
C isn't a high-level language; rather it is a portable assembler. C++ is a fancier, object-oriented portable assembler.
There's a place for C, in writing code for very small embedded systems (perhaps under 16K of memory). IMNSHO, it is only a mediocre language for writing operating system kernels, and a terrible one for writing applications. Ada, Modula-3, Sather, and similar languages are quite suited for writing kernels, and many more languages are well suited for applications programming.
C++ seems well-suited for not much of anything. I have yet to find any convincing argument that C++ is the best-suited language for any particular purpose. The only thing it seems to have going for it is popularity, and one shouldn't confuse popularity with merit.
Oh, that it should be that easy!Eric Smith (who writes C and sometimes C++ code for a living, sigh)
Software Reliability: Don't Use the Wrong Tools
Obligatory C++ quotes:
Spectra6# ./2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Spectra6# uname -sr
FreeBSD 4.9-RELEASE
uhh, i just did roll back recently and it was without a precedent such as power failure, battery failure, or user error. short of my bios containing behaviours, i am wondering if something like this might explain my recent rollback.
"Stratigraphically the origin of agriculture and thermonuclear destruction will appear essentially simultaneous" -- Lee
That's what happens in you live in a Matrix with 32-bit signed integral times.
Me, I'm looking forward to the period from 1905 to 1910 again.
In other words, this is just a very awkward way of doing exactly the same: there are still 31 bits for the integer, and one bit for tagging or whatever.
This sig under construction. Please check back later.
typedef __kernel_time_t time_t;
http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39, line 21:
typedef long __kernel_time_t;
It's defined as a long for the other architectures as well. AFAIK a long is 32 bits on all platforms Linux 2.0.39 runs on.
This sig under construction. Please check back later.
All UNIX implementations I've come across are implemented in C, not C++. Happily, the most current ISO specification for C is C99, where "long long" is defined.
In either Perl --snip-- the language actually cooperates in helping the programmer write robust software.
What are you smoking? The reason Perl is described as line noise is because that's what it looks like. The only character in history that could speak line noise is the Terminatrix! And she's a fucking fiction!
If Perl cooperates in helping me write robust software then I've got two penises.
Like what I said? You might like my music
#define MIN_CHEST 25
size_t chest;
Minimum diameter 25! Whoah! Are you sure you don't mean circumference?
(BTW, I'm assuming inches. Maybe that's where I'm going wrong?)
This SMTP server stores the time to next retry sending a message but only the last 9 digits. So come mid 2001 Webshield would no longer retry sending a mail if the first attempt didn't work. Because it concluded it had been about 30 years since it last tried and it should give up about now.
There is a hot fix available, but this insidious problem only manifests itself if there is a problem at the receiving end so few people know they should upgrade and blame the recipient for mail that bounces immediately. Network Associates still provide software unpatched - hot fixes are only to be applied if you report he specific problem to be fixed.
If you use tempfailing (greylisting) as I do, then this immediately stuffs up any Webshield user trying to communciate with you because they will not retry after being given a temporary failure SMTP error code.
So if this example is anything to go by, then yeah, there'll be recent, modern commercial software that will fail (perhaps in non-obvious ways), with no fix available until after the event.
Recycle PCs and build a wireless community network www.hillsborough.org.nz
I remember talking to a friend who tried to convince me that the earth was going to end somewhere in 2001. Why? Well, it's very simple. The number of the beast is 666, multiply that by three (there was a reason for that too -- not sure what it was, but it was biblical as well). That gives you 1998, and that's the number of years after the birth of Christ that the world is going to end. However, he told me, Jesus Christ wasn't born exactly on the first day of year one, he was actually born somewhere around 3 B.C., so that meant that the end of the world was going to take place in 2001.
:)
This conversation took place somewhere in the year 2000. He was not very pleased to hear that if he were right, the world would already have ended 5 years ago.
thank you Unix for combining data and error conditions into one convenient return value!
:)
I'd love to see the day when one of these functions actually returns an error. AFAIK most C programmers only check error codes on functions of which they expect that they can actually fail when they are used correctly. Getting the current time is not one of these functions.
OK, to be fair, I'll quote the list of errors from the time(2) manpage:
EFAULT t points outside your accessible address space.
So the only thing that might cause this is a case of programmer stupidity. I'm not sure whether this error set is specified by POSIX however, so other systems might be able to return additional errors. For instance:
* EWORLDHASENDED past 21 March 2008 on The Lord's Witnesses's fork of Jesux
* ESCOLICENSENOTPRESENT on the latest, fully security patched versions of Caldera Linux, etc.
I'll be laughing my ass off when a system gives me a timestamp in 2116.
Regards
elFarto
And for extra paranoid people, make all values unsigned.
You should learn from Unix and Xfree86 -- just recompile everything!
The question is, do we want a uniform and precise time scale, or a time scale that is kept in synchronization with the rotation of the Earth, at the expense of unpredictable discontinuities.
Mea navis aericumbens anguillis abundat
I say, let be REALLY geek, from now on I'll use this : http://www.l9c.org/age.php to get my binary, unix timestamped, age and birthday date ! 967 Mis old, approaching the Gis !
Kirinyaga
And how do we know this isn't overblown just like Y2K?
Pelé!
Dates were usually stored as character strings or in BCD format on older systems. It was more efficient in CPU time than using integers. Many computers did not have hardware for doing multiplication and division. Even if they had the hardware, multiply and divide were usually much slower than the other ALU operations. It was easier and faster to use BCD or character strings.
Mea navis aericumbens anguillis abundat
Wrong.
The Newton has two clocks: minutes from 1904, and seconds from 1/1/1993. In addition, integers are only 30 bits wide. And signed.
I wrote a system patch called Fix2010 for the Newton to deal with this problem. Let me quote from the readme:
And this is not a problem at all. Just declare a wider variable and assign the return value of time() to it, an you'll have a wider time to play with. The fact that it returns a 32 bit value will only matter 30+ years from now.
Pedro Côrte-Real.
My date(1) insists that I always provide the $$, since arguments for processing the %s can be difficult to process.
Not to mention all the "hero" points we get for swooping in at just the last minute to save the day; what, you don't think Superman could have gotten to the railroad crossing more than 20ms before the train and avoided using his own body as an emergency-substitute rail? He's freakin' SUPERMAN, man!! He could'a flown there, spot-welded a new overpass with his heat vision, taken a latte' break and still had time to stop Lois from even stepping into the quicksand, but all he'd get then is a "Gee, Superman, thanks; these slingbacks cost me half a paycheck!" instead've that doe-eyed swoon he always gets!!
Yeah, the poster got the dealie with Lisp entirely wrong. It's a C/Unix problem, which has nothing to do with Lisp itself, but an implementation detail. Most systems have moved or are moving to 64-bit time_t's already, so this problem will go away over time. It can't really be fixed by an implementation, unless the implementation happens to be running before and after the rollover, and notices what's happened.
There are already reference libraries available that work with 64 bit time values, such as TAI (Temps Atomique International). See libtai for more info. I like the following quote: "Under many cosmological theories, the integers under 2^63 are adequate to cover the entire expected lifetime of the universe; in this case no extensions will be necessary."
The main problem is crossing the before/after boundary of converting from 32- to 64-bit times. All of a sudden you need two sets of programs to deal with data, depending on whether it was written before or after the switch. Think backups. Think binary database dumps. Panic.
Your solution requires a recompile once time() is changed to a wider result. I want a solution that doesn't require a recompile. Why? Ask all those people who didn't think that their 1975 code would still be running in 2000 when the Y2K problem struck.
Also, I want to know NOW what the exact fate of time_t wil be -- will it be widened or replaced by another data type? I don't think that's an unreasonable request.
In addition, your solution requires every programmer to take special proactive action. I'd prefer a solution that simply "just works" rather than depending on every programmer doing something special.
You raise some interesting points about C++, but all I want to do is just get a simple problem fixed that has gone unfixed for too long.
Instead of saying "C++" in my original post, I probably should have said "all languages that have a time()-like function that allows the implementation to return only 32 bits".
I think it's important for it to get fixed in C++ because C++ has such a big influence on other languages.
#perl testime.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
# uname -rs
Linux 2.4.18-3
This is 7.3 (Time to move to AS?)
If you don't want to repeat the past, stop living in it.
Well, partially wrong.
A lot of modern Japanese publications are written left-to-right (Computer manuals) but the year-month-day progression is traditional and makes a hell of a lot more sense. Being Canadian we suffer the confusion of governmental dates being in British order and business dates being in U.S. order. I leave our computers in U.S. order at installation as it results in MUCH fewer problems.
If you don't want to repeat the past, stop living in it.
A few years back I was working on a custom application for one of the "big telcos" - I made sure date entry fields would accept five digit years because you KNOW anything a telco runs is going to be around at least that long.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I didn't say that Perl was a particularly great language, or that I recommend it for writing complex programs. I only said that it doesn't have some of the problems of C and C++. It adds new problems to compensate.
Take FFFFFFFF and subtract 1072121762
perl -e 'print "seconds left: ", (time), "\n"'
seconds left: 1072121762
and you get 100 years
Panic! Run around in circles screaming, help, panic!!
Just don't run windows and your life will be so much better.
$ perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
$ uname -mrs
CYGWIN_NT-5.1 1.5.5(0.94/3/2) i686
grey wolf
LET FORTRAN DIE!
I was thinking of software, like:
;sleep(1);} '
perl -e 'while(true){printf "%b\r", `date -u +%s`
A fancy odometer-style display would be nice but I can live without it.
but is secretly wondering why you're still using it on a P90 in 2094
;)
Because Intel may never go out of business and at one point they will ditch their PII, PIII, PIV [...] scheme as soon as processor naming reaches PentiumXXX. Therefore, the shelves will once more say P5, P10, P60, P89...
"Wireless : LAN
We already hit 1Bsec two years ago. Slashdot's article on this is disturbingly missing (note article title), but luckily this link lists the milestones.
But we're talking about 1.073 billion here, a 'gig' of seconds, not a billion... c|net just doesn't know a damn thing, even after all these years.
(Does it disturb a single other person than me that reporters for technology sites don't know any more about computing than reporters for, like, Fox News?)
Anyway, have a merry 1072310400.
Terrorists can attack freedom, but only Congress can destroy it.
Great, now SCO is going to claim you copied that Perl out of System V, and take down /. on a DCMA claim.
[zaschitnik] # perl 2038.pl Tue Jan 19 03:14:01 2038 Tue Jan 19 03:14:02 2038 Tue Jan 19 03:14:03 2038 Tue Jan 19 03:14:04 2038 Tue Jan 19 03:14:05 2038 Tue Jan 19 03:14:06 2038 Tue Jan 19 03:14:07 2038 Fri Dec 13 20:45:52 1901 Fri Dec 13 20:45:52 1901 Fri Dec 13 20:45:52 1901
I was showing the parent how the bit assignments would have to be changed to use the shift method of extracting values.
You'll notice that in my revised example scheme (no pun intended), there is no distinction between even and odd integers.
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
(In your link, notice that further down the page, a semicolon appears outside the quote in a similar situation:Does this make sense to you?
It doesn't to me.
Note that a similar situation exists for parenthetical sentences/phrases:.
it makes no sense to me that the period (and comma) should be exceptions to this (very logical) rule.)
Logically, the sentence should have ended with, one period to end the sentence within the quotes, and one to end the sentence without (i.e., "outside of") the quotes.
So the logical way to have ended the sentence would have been:However, that looks funny to me.
IMO, quote-period is the better choice between quote-period and period-quote, because quote-period ends the entire sentence, whereas period-quote logically ends only the sentence within the quotes.
(At least, that's the way that it looks to my computerphilic-parser mind.)
From now on, though, I will use two periods.
Satisfied?
Those who sacrifice security to condemn liberty deserve to repeat history or something. - Benjamin Santayana
When I said 'this is just a very awkward way...', I was referring to the scheme in your post's parent. Wich, as you demonstrated, doesn't have any added value. So I think you and I are saying the same thing here.
This sig under construction. Please check back later.
"Tomatoes."
Shop as usual. And avoid panic buying.
look like solaris 9 doesn't roll either
$ perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
$ uname -a
SunOS station 5.9 Generic_112233-08 sun4m sparc SUNW,SPARCstation-20
$ perl -v
This is perl, v5.8.0 built for sun4-solaris
iF yOu WAnT to C YOUr iP agaIn gAThEr tWO MilLIon dOLLArS IN Non - cONsEcuTivE TweNtY's AnD AWaiT FuRThER iNstrUctIoN
Seriously people. You actually *DONT* need to represent times (rememberdates are large times) before the epoch. At least not in the scope of the time_t data type.
The scope of the project and standard in quesiton is represent "now" (the current time) and to place, track, and manipulate time signatures for operating-sytem level events. You know, things like "date file created" and "date file last modified" and so forth.
The time_t type exists to let directory updates and newer-than/older-than comparasons happen in "very small, linear time" so that it is cost effective to, say, search a directory in chronological order or see if an object file needs to be recompiled.
Go see how porly these functions work using windows networking accross a slow link and you will get an inkling about why this speed vs limit tradeoff is important.
There is no rational need to represent a "now" of such historical scope WITH RESPECT TO AN OPERATING SYSTEM DATA.
Yes, some idiot programmers out there are using this time_t datum in "very bad" contexts. Databases of historical fact that are expected to contain items predating the epoc (birth registries, deed and title search databases, publishing databases, and so on) ARE *completely* unsuited for, and outside the intent of, the time_t "quanta past epoch" representation for dates and times.
Saying time_t is bad for historical dates is "exactly" as valid as mentionting that ASCII is not a good character set for representing hyroglyphs. The word "duh" comes to mind.
In "real data" (as opposed to OS event/contemporary transient data) there are actually two types of "time" the ordinal (spesific date and time) and the inerval (a measure of duration). An actual data storage system (database) needs to have an internal abstraction for storing and "doing math (uniformly) over" and "indexing across" those two abstractions.
So for real data you need explicit structures.
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
I saw this on a DirecTv box. I was at a friend's house on christmas and on the DirecTv info bar it listed the date as 1/08/70. Dunno if it was due to a lazy operater, or this bug. For further info this is a DirecTv receiver built into an HDTV receiver, unsure of the brand, but it is a widescreen. It is about 4 years old, tops.
I hate sigs.