Slashdot Mirror
The Quickly Descending Unix Timestamp
Teach writes: "If my calculations are correct, on Thursday, April 19, 2001, at 04:25:21 UTC (00:25:21 EDT and late Wednesday at 21:25:21 PDT), the UNIX clock will read 987654321, which is pretty cool. This will be the first of two such "significant" events in 2001, the second being 01:46:39 UTC on 2001-09-09, when the clock will read 999999999 (and then of course "roll over" to 1000000000 one second later). Use the Time Zone Converter to help you figure out when this will occur in your area, or read up on other
critical dates (such as when the 32-bit signed UNIX clock overflows in 2038)."
Not many programs are gonna care how many digits are in a timestamp, but I bet some do try to format stuff assuming a less-than-one-billion-seconds-since-epoch time.
Review your code?
[
I hate to crapflood and troll, but this has to be the dumbest article on /.
How are we supposed to discuss this?
Its like when the "annoying" guy comes into your cube and says some dumb fact, like "hey, the timestamp will be 987654321 soon!", and you try to ignore him so he'll go away...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
I thought the Mayans predicted the world would end in 2021.. But if I'm still alive in 2038, I think I'll be more concerned about my next change of Depend Undergarments than what my Unix clock is doing...
Fortunately, the Unix internal clock works in a manner very similar to the odometer on the Slashdot Cruiser. When you go to trade in your Unix system and step up to Windows, all you have to do is crack open the little block box inside your machine and roll it back several hundred thousand milliseconds.
Nobody will know the difference save the occasional hidden-camera "consumer protection" reporterette. These people seem to have nothing better to do than spy on semi-honest computer salesman and publicly humiliate them for the crime of trying to feed their families. We could talk about the silliness of having to disclose whether or not your computer had its case straightened after a minor plastic-bender, but that would be a whole nother post....
Got a full tank of hot grits and a penis bird in the glove box.
I've been having some free time lately, so I've gotten to pondering some questions like these. One of my questions was about why a rational and benevolent deity would allow Survivor II to air on primetime television. The other has to do with the timestamp and a theory of mine.
You see, neither would a rational and benevolent deity allow the unix timestamp to lap like that. The commotion involved would be significantly worse than the Y2K bug was, because at least with the millennium, people knew to be on the lookout for all sorts of strange behavior (not just computer bugs). But 2038? What kind of date is that? Where's your catchy three-syllable mnemonic for that one?
So clearly, there has to be another explanation. Mine is that Armegeddon will intercede and prevent this disaster from occurring. A rational and benevolent deity would realize that it would be far better for the universe to be destroyed than for time to cease.
This poses all sorts of interesting moral, legal, and ethical questions. What should we do about debts that are set to expire after 2038? Should mandatory euthenasia be implemented on all infants born after 2036 so as to avert their agony when the heavens open up and the clarion trumpets of Judgment call forth the arrival of hellfire and brimstone? Will we be able to sublet our cottages in Boca as we've grown accustomed to doing?
This calls for immediate discussion. A committee of learned professors in each of the relavent disciplines (religion, philosophy, sociology, art history) must convene and solve this problem before it becomes the death of us. We have only thirty seven more years left, so let's make the best of it.
So, you have a UNIX timestamp you want to check out? Try Perl on the command-line:
perl -MPOSIX -le 'print ctime(999999999)'
perl -MPOSIX -le 'print ctime(987654321)'
For another timezone, you can just set the TZ environment variable. On the command-line, or in the code:
perl -MPOSIX -le '$ENV{TZ}="CST";print ctime(200)'
Actually, because there are historical reasons for ctime supplying a newline, you can drop the "l" from "-le".
Shouldn't that be ascending since the numbers are going up? Descending implies the numbers are going down, which they surely are not.
[Got Hosting?]
That should teach to overclockers!!
Victor
My car's odomoeter will roll over to 12345 in 93 miles.
perl -le 'print scalar gmtime(999999999)'
And of course localtime() for your own timezone.
Liberty in your lifetime
date -d "$((987654321 - $(date +%s))) sec"
tells you in your local time when that event will happen... (well evntually it is 1 second off if the first date terminates not in the same second as the second... lg mond.
9/9 also happens to be my birthday, so my numbers will be rolling over too. Woooooohooooooo!
> Thursday, April 19, 2001 ... the UNIX clock will read 987654321, which is pretty cool.
OK, but when are we going to get the Slashdot User #987654321 throw-down troll account?
We went from 100000 to 400000 so fast that I wouldn't expect it to take too much longer.
--
Sheesh, evil *and* a jerk. -- Jade
I have something to discuss .. like, why does no one think its fun to know when it happens? Has the market bust turned all us geeks into blinder-wearing profit-seeking business types? How useful is the obfuscated Obfuscated C Code Contest? But geeks still seem to dig it ... :) While I may not be staring at 'while (1) { printf("%lu\n", time()); }' when the rollover happens, at least its cool to know we lived the moment! It only happens one in one billion times!
"Old man yells at systemd"
When UNIX makes this mistake it, it's "pretty cool". What would it be if MS-Windows did it?
"You know you don't act like a scientist, you're more like a game show host." Dana Barret
I think the best solution to the year 2038 bug is simply to roll everybody's clock back to the year 1970. Problem solved!
Besides, disco was so groovy, wasn't it? Yeah, baby, yeah!!
--
Accountability on the heads of the powerful.
Power in the hands of the accountable.
The other significant thing that will happen on that date is that moderators the world over will be confused, wondering if the moderation guidelines actually changed or not.
(This is in reference to the message moderators get saying "Have you read the Moderation Guidelines yet? Updated 9.9". They were updated 9/9/1999, which I guess was such a cool date that they never bothered changing it again, just updated the FAQ. Of course, saying "Updated 9.9.99" would be even cooler. Maybe CmdrTaco is waiting for 1.1.11 to update them again, or even 2.2.2222...
Not being helpful doesn't make it a troll
--
In case you were wondering, unixtime 123456789 occured on
Thu Nov 29 13:33:09 1973
(please do not waste mod points on this post, thanks)
...that anybody still using a 32-bit system in four decades deserves what he gets.
Come on, does that sound so likely? Four decades ago you were lucky to be able to afford all 8 bits in your 8-bit system. And the graph is not a linear one (think Moore here), so four decades from now they'll be laughing at us for working in such a cramped 32-bit address space.
Solaris has been 64-bit for years now. Same for a number of other Unixes. If somebody is honestly worried about time_t, tell him that a 64-bit time_t can hold more seconds than the probable remaining lifetime of the universe.
The Divine intent is the same here as it is for folks driving fast in highway construction zones: stupid people deserve what happens to them.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Whether or not UNIX will be running before 1970, it still might be useful to store dates before 1970, such as birthdates, etc.
I dunno, but that sounds like one of the best excuses for a geek party I've ever heard.
;-)
Heck, that might even be a big enough party to be called a "Conference."
... with the command:
watch -n 1 date +%s
or better yet:
watch -n 1 'echo "The time is near: `date +%s`"'
I think the best solution to the year 2038 bug is simply to roll everybody's clock back to the year 1970
There's a simpler solution: typedef unsigned long time_t; should take us into the 22nd century before we have a problem. (The DJGPP C library already does this.) Another solution is typedef long long time_t; which is on nearly the same order of magnitude as the best estimates for the age of this universe.
Will I retire or break 10K?
Also, I don't know if this is just a Perl thing, but dates "past" 2**31-1 (i.e., negative numbers when "signed") seem to be used to represent dates far before 1970.
For example:
% perl -le 'print scalar gmtime(2**31)'
Fri Dec 13 20:45:52 1901
% perl -le 'print scalar gmtime(2**31+2)'
Fri Dec 13 20:45:54 1901
% perl -le 'print scalar gmtime(2**31+2**30)'
Mon Dec 23 10:22:56 1935
Liberty in your lifetime
Is there any plan for a *nix wide upgrade to a 64 bit time variable in the next few years? I figure we ought to take care of this now, otherwise the entire *nix community will be mocked by the Windows and Mac communities in the 2030s. Let's just get the upgrade over with and not have to worry about it in the future.
"The universe seems neither benign nor hostile, merely indifferent." --Carl Sagan
Is there any logical reason for the date to be using a signed number as opposed to unsigned?
I assume that the architects of the system wanted to represent their date of birth. It's the same thing that motivated the Mac OS designers to choose 1904 as the Mac's (unsigned) epoch.
Will I retire or break 10K?
3/3/2001 - all sections add up to 3. Also, it's an Odd Day - all non-zero digits are odd, AND all sections are odd, AND all section's digits sum up to odd totals. Since these are also all prime, it was also a Prime Day.
Trivia Question: When will be the next Prime Millisecond, as measured by RL -and- by the Unix clock?
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
All about me
maybe you or the cops you do realize it's illegal right?
No it's not, I can go out and buy some right now, walk over to the police building and offer some to one of the officers, he'll probably smile at me and refuse the offer.
just because it's illegal in your lame-ass country doesn't mean it's illegal everywhere
---
it depends on the UNIX. Solaris (sparc), Digital Unix, etc, are all 64 bit already as they run on 64 bit processors.
There is at least one application out there that had a problem with the September 9 rollover of the UNIX time stamp.
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
of an access to a website, etc. that has a Unix time counter (if that's even possible)? And what's the significance of the date chosen to be time 0?
---
---
I'm just an ordinary man with nothing to lose.
This is useable and sensible. I can see this.
[inserting tongue in cheek]
But we might not need to worry because of all of the other disasters that are proposed to be happening between now then then, including the end of the Maya Epoch (get your Mayan Date TShirt here, and the destruction of civilization by asteroids in 2028 (orbit info here, Seattle Times disinfo here, commentary here)
And, with the crashomatic feature in MS OS software, the world will come to an end well before that when the MS .NET system gets hit with a succesful .NET virus that wipes out lots of data from the hard drives. Of course, it will be a MS email virus, that scans the network for vulnerable files.
Check out the Vinny the Vampire comic strip
"It is a greater offense to steal men's labor, than their clothes"
... would be 7f6. (As in 0x7f6)
Works in hex too (only 4 69's allowed, sorry...):
>perl -MPOSIX -le 'print ctime(0x69696969)'
Thu Jan 15 20:25:45 2026
that's why I have my Gnome desktop clock displaying UNIX time:
987628906
987628907
987628908
.
.
.
Energy: time to change the picture.
32-bit systems can only store a maximum of 2^31 non-negative seconds (2,147,483,648 seconds or about 68 years). Which means that 32-bit UNIX systems won't be able to process time beyond 19 Jan 2038 at 3:14:07 AM UTC.
One of the common solutions will be to switch to 64-bit architecture systems that can store a maximium of 2^63 non-negative seconds (9,223,372,036,854,775,808 [9.2 Quintillion] seconds or about 292.27 Billion years), which would be sufficient for quite a long time!
I can't wait for the MSNBC story about this one.
Redmond WA.
Today Bill Gates announced that all *nix systems will halt with the September 9th coming of the S1B bug. MSNBC recommends that all *nix users switch to Windows XP before it is too late. Steve Balmer was reported to say how amazed he was that *nix could be so short sighted. XP was designed to be S1B compliant right from the start (after installing SP8 due sometime in September). All you Windows users will be kept safe from this, and should not consider going to any rogue operating systems at this time.
If you haven't checked out the Critical Dates link, it's fascinating (if somewhat repetitve) reading. Just think! Someone actually figured out that, on Tuesday, January 1, 29602, NTFS fails! I'm thinking, if you're stilling using NTFS in 27,000 years, you're probably gonna get what's coming to you.
Meet your fate in '38!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I think this would be a cool idea for a party. The clock rolls over to 1G from 999999999 on the 9th day of the 9th month of the millenium. How cool's that? The 9/9/01 is a Sunday, so it's even kind enough to be on a weekend.
So pack those beers, grab the munchies, set up a *n?x computer with a BIG display showing the countdown and invite all your appreciative geek friends over. Forget the end of the millenium; the stupids celebrated it a year too early anyway. This is the REAL once-in-a-lifetime event....
--
The only thing necessary for the triumph of evil is for good men to do nothing. - Edmund Burke
Hypothesis: God wants us to use 64 bit processors.
Corollary: Every IA-64 delay makes it more likely that Intel executives will burn in hell.
So let me get this straight the mightiest country in the world The United States of America is lame?
yes it is. all this talk about how much freedom you're supposed have when in fact it's not that free at all.things like softdrugs and prostitution are illegal, you'll probably say that it's not good for you to use softdrugs or not moral to go to a hooker, but at least I made that decision for myself instead of that the government made it for me.
I have the freedom to choose and set my own standards, you don't.
---
Probably Holland.
yepBeen there once, very interesting place. Friendly people and travelling is really easy due to the excellent mass transportation systems. I dunno why Amtrak and friends even bother anymore :(
actually, they're working on making the trains run better according to schedule.nowadays you can even get a refund if a train is delayed too long
---
Why don't we move to a 64 bit timestamp?
My primary occupation is to build ASP applications in PHP - and the 32 bit timestamp is a decided limiting factor.
So we move to a 64-bit epoch - I don't see any particular problem doing so NOW... but in 37 years it just might be a REAL PROBLEM.
Why isn't this done? Why don't the kernel developers for Linux just do this, using a slightly different system call? (xtime() instead of time() or whatever)
A compatability function could SO EASILY be added now, and then software can be written that takes advantage of the extended API...
I have no problem with your religion until you decide it's reason to deprive others of the truth.
The Java date subsystem was apparently designed by a short sighted individual. Who would use a signed number to represent the date? They could go twice as far into the future if they used it as an unsigned number. After all, time didn't exist before 1970 so it's perfectly okay to just represent it as an unsigned number.
Sorry, but seeing bad programming practices like this just make be a little upset especially for a supposedly robust system such as Java.
Things you think are in the Constitution, but are not.
--
--
Mod up a post Rob doesn't like and you'll never mod again
I wrote a program which used the current time *2 as a 10-byte IV. When the time rolls over, that program will fail. Why was I doing such a dirty trick? I was trying to squeeze every last byte out of an RC4-based cryptosystem written in Perl.
; for$x(@t=@s=0..255){S
The bug was spotted by co-author Jeff Allen, who suggested this fix: *invert* the time with "~". That should keep going until the 32-bit clock runs out in 2038.
#!/usr/bin/perl -0777i_MUNITION,see_http://ciphersaber.gurus.com
(pop)?read STDIN,$p,10:print$p= ~time;sub S{@s[$x,$y]=@s[$y,$x]}sub
Q{$s[($_[0]+=$_[1])%=@s]}@k=unpack'C*',(pop).$p
Q$y,$k[$x%@k]+Q$x}$x=$y=0;print map{chr($_^Q S Q$y,Q$x,1)}unpack'C*',<>
I've had to introduce a space in ";for" to get around Slashdot's random space adding system (bah!) - the minimal version is on my Web pages. Incidentally, the ~ fix didn't save a character, because we still had to leave a space between the = and the ~ since =~ is a distinct Perl token...
--
Xenu loves you!
Some people theorize that rather than the magnetic polarity of the poles switching, the weight of the icecaps on the poles will cause (and has caused before) the crust of the earth to actually slide over the molten center, as if it were an orange with a loose peel. This would, of course be a highly catastrophic event. Suddenly, the poles are at the equator, the oceans slosh out of their basins, scouring the continents...
Check out "Footprints of the Gods" by Graham Hancock for more details about this and other far-out but suprisingly well researched and supported theories.
Not exactly a fair comparison since what you used above produces output like:
Apr 20, 2001 12:57:09 AM
Whereas localtime() gives you back a struct! The eqivilent is more like new GregorianCalendar() which gives you a handy calendar for the current locale and the current time (more than you'd get from a struct tm actually!) from which you could extract month/day/year/etc. fields.
Now, as for outputting that struct in C the same as the Java code you gave, I won't go into that. I will show you two ways to shorten the Java though:
1) new Date().toString() produces:
Fri Apr 20 00:57:09 PDT 2001
(not localized)
2) If you need the output to be correct for your locale, you can shorten what you had a little:
DateFormat.getDateTimeInstance().format(new Date()) )
Which doesn't look so bad, considering all the benefit you get from it!
The summary - use new Date() instead of Calendar.getInstance().getTime()!!
"There is more worth loving than we have strength to love." - Brian Jay Stanley