Slashdot Mirror
February 13th, UNIX Time Will Reach 1234567890
mikesd81 writes "Over at Linux Magazine Online, Jon maddog Hall writes that on Friday the 13th, 2009 at 11:31:30pm UTC UNIX time will reach 1,234,567,890. This will be Friday, February 13th at 1831 and 30 seconds EST. Matias Palomec has a perl script you an use to see what time that will be for you:
perl -e 'print scalar localtime(1234567890),"\n";' Now, while this is not the UNIX epoch, Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."
Is that with or without leap seconds?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Slow news day, as fark would put it?
perl -e 'print ~~ localtime(1234567890),"\n"'
perl -e 'print localtime(1234567890) ."\n";'
Let the "." concatenate operator do it for you.
Infuriate left and right
...it's my birthday. I've been telling people for years that my birthday is at 1234567890.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
...that I really feel I missed:
$ perl -e 'print scalar localtime(8675309),"\n";'
Sat Apr 11 11:48:29 1970
It is dangerous to be right when the government is wrong.
Perl, because `watch date +"%s"` is too easy?
So the time is 123456789? That's the stupidest time I've ever heard in my life... It sounds like something an idiot would have on his luggage.
Wow, you must have a hard time finding joy in anything.
I just pooped your party.
1234567890 is some arbitrary decimal string, if you wished to note a notable number, why not one which is 2^N, for something so entirely based within computers, it seems much more sensible to think in binary than some decimal number which happens to look a little pretty
Longest sentence ever.
The standard unix date command will suffice:
date -d @1234567890
2^30 already passed us by (Sat Jan 10, 2004 at 08:37:04 EST) and few of us will be alive for 2^32 (Sun Feb 7 2106 at 01:28:16 EST), but 2^31 is right around the corner! (Mon Jan 18, 22:14:08 EST).
1234567890 GET!
Oh I love a good GET. Hope it's not a furget again though.
11.23 seconds later UNIX time will reach 10^11/3^4. You can celebrate that instead.
Fri Nov 7 01:00:10 5451
I mean seriously... why is 1234567890 such a special timestamp? Where was the article when we crossed 123456789 ? :)
As for Linux using 64-bit time, that's great, but many applications still were compiled with a 32-bit time_t
Or use 32-bit integers to represent the time saved in binary DB structures, where it's not so trivial to convert.
The OS itself may live past the 2038 32-bit time_t rollover, but the same cannot be said about all mission-critical apps that may be running on top of the Linux OS.
An OS is nothing without database apps, business apps, etc, some of which source code may not be available for, some of which may be unsupported abandonware by the time 2038 rolls around.
For example, do MySQL and postgreSQL use 64-bit date values exclusively now?
What about apps that were already written and use ordinary ints to hold time_t values? They'll have issues just like the Year 2000 issues that were a problem 10 years ago.
Aaaaargh, the end of the world!!!!
I guess I'll have to wait until 2012 for the end of the world.
What is it with geeks and time?
It always surprises me when this sort of "news" makes the front page.
I mean, I'm a geek, but even I think this is lame.
Falun Dafa is good!
Sounds like an epic get.
Good question:
http://en.wikipedia.org/wiki/Unix_time
the times it represents are UTC but it has no way of representing UTC leap seconds (e.g. 1998-12-31 23:59:60).
I don't think there's any defined way for a POSIX machine to deal with leap seconds. The usual solution is to slew the clock a bit after they occur.
AccountKiller
Go back to 4chan, faggot.
you wont need it after all
> Mon Jan 18, 22:14:08 EST
I disagree: Tue, 19 Jan _2038_ 03:14:08 GMT
See also, the 2038 problem.
http://coolepochcountdown.com/
The World Wide Web is dying. Soon, we shall have only the Internet.
Just wait till Unix time reaches 3141592654 (sorry I rounded up the last digit on the holy number, if its that bad you can celebrate a second earlier) If you think people get crazy about pi day wait till you mix pi and unix.
http://www.aaronrogier.net
where is the typo in tags tag??
It's also a run-on, that first comma should be a period or at least a semicolon, and then the one before for should also be a period.
All your base are belong to Wii.
1234567890 + 13 = ?????
This could easily be numberwang. Fetch my broom.
No, you didn't get it, it's not arbitrary. The digits are all in order! Look at the numbers above the letters on your keyboard, they're in the exact same order from 1 to 0. Cool, huh!?!
I believe thats the correct date
Prickle-Prickle, Chaos 44, 3174 YOLD
this of course will be happening on Sat Feb 14th .... at about lunch time here in NZ .... earlier that day (at breakfast) it will be 1234554321
Longest English sentence
fortune favors the lucky
Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."
This is just the sort of short-sighted thinking that lead to our recent Y2K hysteria, except this time our poor beleaguered descendents will be in the middle of an exodus from the solar system when all their legacy systems throw simultaneous exceptions. This will of course cause their engine and guidance systems to fail, so that the last dying gasps of humanity will consist of:
Sun 21 Jul 2069 00:37:34 UTC
That's if we survive that long. I'll bring the geritol, you fetch the liquidised boiled fish and mashed potatoes ;o)
It seems I must include a meme when posting AC, so at least we'll be able to use e-mail in Korea...
The rest of the world is enjoying Valentine's Day with people important to them. Damn :)
and by 2038 NOBODY should still be using a 32 bit Linux , for that to even matter. But 1234567890 == fri 13 is a bit of fun
"I don't pitch OpenSUSE Linux to my friends, i let Microsoft do it for me
First pandigital number with the digits in order GET http://en.wikipedia.org/wiki/Pandigital_number
>UNIX epoch 'roll-over' would happen about the time that the sun burnt out."
Yes, that will be a nice little surprise for whatever cyborg/singularity we've evolved into as they try to flee to a habitable star system in their linux controlled vessels.
Linux will doom us all.
BG
even though this is the wrong forum, i wouldn't know where else to put the put the request, so here goes:
time measurements usually work from sometime in the 1970s, or maybe back to the 1800s, and peter out in the 2000s, or perhaps go to something like the year 9999
completely dismissed in all of these schemes is historical time, over which there is valid reason to take measurements and establish dates
why not, instead of going to some absurd future date in milliseconds, pinpoint the start date in the distant past? say around the time the pyramids were built. you could still go to some absurd future date in milliseconds
of course, then there is the issue of exactness. however, even without all of the changes in time measurements over history, we ever could firmly establish certain dates and times
no one is promising that the precise millisecond king canute was born or zheng he left port can be pinpointed
but it would be very useful for genealogists, or climate researchers, as well as just plain history software
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
date -d @1234567890
does not work on my Fedora Core 5 machine. Which is not that old.
The perl script works more reliably.
Not if we start counting at a much finer resolution. I mean, after all, seconds are so...Last Century.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
this is pretty insignificant, if we used base 13 math we'd get 168a0865a ,only special in base 10 which doesnt mean much, just silly human standards
"arbitrary decimal string" ... aren't we celebrating a common password?
However, considering that OSX is based on BSD, you can also get Apple pi.
Good, inexpensive web hosting
it's my password... now everyone know it, thanks SLASHDOT! :-)
nop, nop, nop #VBLANK
Yes, it's a slow news day and that's why this is on the front page! It's Sunday afternoon (for most of us), ferchrissakes.
So just enjoy it, it's geeky and novel. I don't think anybody meant for it to be considered a big deal, and if you don't find any fleeting moment of joy from it, just move along.
THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE
Children are starving in Japan? I don't get it.
Facebook is the new AOL
Raw unix time is simply a count of seconds since a defined point in time - and has nothing to do with leap seconds. Leap seconds only come into play when converting to human readable display format (along with timezones and DST). Leap seconds have been handled for some time by the zoneinfo library used by most unix and linux distros. Even Java handles leap seconds with my port of zoneinfo to a Java TimeZone implementation.
The tzdata package included in most Linux distros includes leapsecond data in the "right" directory. You can find out the time including leapseconds by setting your TZ environment variable to "right/...". For instance:
$ TZ="right/US/Eastern" date; TZ="US/Eastern" date
Sun Feb 8 17:52:42 EST 2009
Sun Feb 8 17:53:06 EST 2009
So you've never read Kant or Hegel then?
Justice is the sheep getting arrested while an impartial judge declares the vote void.
Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out."
So great, we're going to be dealing with the 64bit time roll over in the dark? What kinda planning is that! Do we have candles?
What about 6.03x10^23? :D
And you can google for some who didn't get by Y2k...
If you think people get crazy about pi day wait till you mix pi and unix.
Mmmm... pi...
Usage: km/h for speed (kilometers per hour); kph for very slow impulses (kilopond hours).
1234567890 is some arbitrary decimal string, if you wished to note a notable number, why not one which is 2^N, for something so entirely based within computers, it seems much more sensible to think in binary than some decimal number which happens to look a little pretty
Why do we have gaydar but not virgindar?
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
... for any application that assumes sizeof(time_t) is 32 bits.
Not that I'd expect that to be the case with any half-decent intelligently written application. But we all know how common applications which are neither half-decent nor intelligently written are...
Protip: the women who bother reading this story are probably at least somewhat interested in the subject, and thus won't be impressed by you showing how uninterested you are.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
start looting & rioting or get in your bunkers.
Actually thats too big to be stored using a 32 bit number, so the localtime function wraps it around to: Wed Jun 14 11:09:18 1933
Ok, with GMT+1 I got:
$ perl -e 'print scalar localtime(1431655765),"\n";'
Fri May 15 04:09:25 2015
doesn't ring a bell.. (even considering both dates are FRIDAY in italy, which was already a cool day). But moving on:
$ echo 'obase=2;1431655765'| bc
1010101010101010101010101010101
cool!
nop, nop, nop #VBLANK
First thought: "Wait, wasn't that almost 180 years ago?"
A rather geeky friend of mine has already released an app named UnixTime to let you enjoy this historic event on your iPhone/iTouch:
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=303467372&mt=8
http://markdamonhughes.com/UnixTime/
(no, I have no sponsorship deal, just thought if it was geeky enough to be worth writing, it might be geeky enough for some of you to be worth buying)
who the hell cares?
I read Slashdot for the headlines, because the headlines, unlike the articles, are usually original and never duplicated
And it's a Friday.
987%$/#$& [no carrier]
I'm in Australia, so it will happen on the 14th.. my birthday is on the 14th as well... SHAZAM!
Protip: the women who bother reading this story are probably at least somewhat interested in the subject, and thus won't be impressed by you showing how uninterested you are.
Yeah because if one thing from my post is clear, it's that I'd totally go for a chick that'd find his comment interesting. Maybe I could flirt with her by tugging on her third ponytail.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
Hmm. I don't know what posessed me to make that post, but I wish I hadn't. That was shitheaded and patently undeserved. I'm sorry.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
My girlfriend JUST told me about this article!!!
BEST valentines day ever..
Do you really think that won't be patched 20 years from now?
http://www.aaronrogier.net
Not so. UNIX time is strictly defined in POSIX, as are the arithmetic relationships between it and human time, e.g. a time_t % 60 gives you the elapsed seconds in the current minute, which would not be true if unix time included leap seconds.
What you are describing is TAI, or International Atomic Time. If you were to choose to run your system on TAI, you would need some conversion routines if you wanted your system to remain POSIX compatible (which is what modern unix/linux apps expect) -- e.g. time() and stat() would need to continue to report unix-time values, and you'd need TAI-compliant library functions to request the equivalent items with their raw TAI values.
For more details, see the Wikipedia entry on Unix time.
..wayne..
We're lucky we have LHC broken. Friday 13th, this magick sequence on UNIX.. bring in the running collider - and we might have a surprise waiting just around the.. wait, where did that corner go??
the UNIX epoch 'roll-over' would happen about the time that the sun burnt out.
Perhaps the roll-over will be the cause of the sun burning out.
Since we are logically zero based, a meaningful series would be 0123456789, not 1234567890 which just seems wrong here in computer land.
To perl the number 0123456789 is merely bogus. "Illegal octal digit..."
Woverly Harris Gooch, IV CTO American Fire and Bomb, LLC
stupid wanker.
I get: ."\n";'
alex@quadruped:~$ perl -e 'printlocaltime(1234554321)
Sat Feb 14 06:45:21 2009
So I call insensitive clods.
like phosphorescent desert buttons singing one familiar song
Since you are just born ... ..
You would be born around 792639715 if I'm not wrong in my math
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
flashy:/home/joe>perl -e 'print scalar localtime(3151592653),"\n"'
Sun Oct 8 03:55:57 1933
-- I have a private email server in my basement.
Login information, eventually credit cards and some extra information like past telephone numbers of past girlfriends etc.. would do!
Just to ste^H^H^Hprotect your identity now you've exposed yourself!
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
I am gratified to see that time() in gnu/linux returns seconds since the epoch. They mention the contradictory requirements of Posix, but opine that it was a technical error, and seconds since the epoch is what they really meant (or should have meant).
NOTES POSIX.1 defines seconds since the Epoch as a value to be interpreted as
the number of seconds between a specified time and the Epoch, according
to a formula for conversion from UTC equivalent to conversion on the
naive basis that leap seconds are ignored and all years divisible by 4
are leap years. This value is not the same as the actual number of
seconds between the time and the Epoch, because of leap seconds and
because clocks are not required to be synchronised to a standard refer-
ence. The intention is that the interpretation of seconds since the
Epoch values be consistent; see POSIX.1 Annex B 2.2.2 for further
rationale.
... for the number of seconds since the epoch (1 Jan 1970). Instead, what we should be doing with 64 bits is the number of nanoseconds . Keeping the same epoch and using a signed 2's complement 64 bit value with a resolution of 1 nanosecond, it will not overflow until the year 2262, on Friday, 11 April, at 23:47:16 plus 854775807 nanoseconds. Who thinks we won't be using 128 bit (or greater) machines (if bits will even matter) by then?
Of course this means we have to create a new function call and type name, since programs already using time() and time_t expect a number of seconds. I propose the names timens() and timens_t for nanoseconds, timeus() and timeus_t for microseconds, and timems() and timems_t for milliseconds. All these can be library implementations that use a kernel specific syscall to get the actual time at the best suitable resolution and convert as needed.
now we need to go OSS in diesel cars
Thanks for the demonstration. I always gets to me when some nut pulls something out of their ass, when they could have easily checked and found out they were wrong, just by taking the insignificant trouble of googling or entering a simple, short console command.
It doesn't matter how NTP protocol represents time - as long as it can be unambiguously converted to system time (i.e. just about anything except posix time could be used). The leap second flag *is* a little weird, but is just a wrinkle when converting to system time.
crash my Linux box or otherwise disturb my downloading of the return of "Terminator" and the premiere of "Dollhouse" that night, I'm sure I'll survive.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
You are right about the posix definition. But the posix definition is stupid and useless, because it can't unambiguously represent a timestamp - so it is ignored or reinterpreted by sane unix implementations. You can convert a sane clock (like the traditional second count) to posix time (or even most insane localtime based clocks), but not vice versa. So if anyone actually has to run a posix compatible application that is actually braindead enough to rely on time()%60 == seconds_in_minute, then they can set an environment to convert the output of time().
The linux man page for time() mentions the posix definition, and then says they made a mistake - and they really meant seconds since the epoch.
I think you're having some trouble with overflow. Try 64 bit:
[bishop@cluster ~]$ perl -e 'print scalar localtime(3151592653),"\n"'
Wed Nov 13 12:24:13 2069
32 bit:
bishop@home $ perl -e 'print scalar localtime(3141592653),"\n"'
Wed Jun 14 13:09:17 1933
Dude, I think you need a hug.
Oh, for the days when sig's didn't have to be cute...hey, wait a sec.
Wake me when they get to 5318008618
If my call is important, why am I talking to a recording?
Civil time is "baroque" but usable - every instant has a name, however complex the naming convention. Posix time is "broke" - it can't name every instant. Sane unix systems use a simple second count, which is both simple and usable, and can be converted to posix time when needed (hopefully never).
Civil time represents positive leap seconds as second 60:
23:59:59
23:59:60
00:00:00
00:00:01
DST is disambiguated by the Timezone name:
November 2, 2008 1:00:01 AM EST is an hour later than November 2, 2008 1:00:01 AM EDT.
Actually in Australia will avoid the end the world as it will fall on Sat Feb 14 09:31:30 2009 - Just in time for Valentines day
That's only useful if it's an old MacBook Pro, then you have hot apple pi
php -r 'echo date('r',1234567890)."\n";'
I've got screenshots of my Terminal window when it was 1111111111. Happened during the middle of a LUG meeting, by chance.
Also, this gives me a new default timestamp for when I manually tweak a database. I used to enter '1111111111' when I needed a timestamp in the past and it didn't matter what it was... now I can use 1234567890! :-)
In other news, I can't believe they're remaking 1234567890.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I tested this out on a 32 bit Linux box and a 64 bit Linux box. My 32 bit box only went up to year 2038. My PPC64 went up to 2 million or so.
Ops, I shuld have usd the prevuwe but in.
Now, while this is not the UNIX epoch, Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out
Linux marketshare by the 64-bit roll-over will probably have risen to 5%, so a lot more people will be affected by that rollover...
Can you imagine my disappointment:
coffee:/home/fire# perl -e 'print scalar localtime(1123581321),"\n";'
Tue Aug 9 05:55:21 2005
Any suggestions?
This date is actually on Saturday, the 14th of February 2009:
perl -e 'print scalar localtime(1234567890),"\n";'
Sat Feb 14 12:31:30 2009
So therefore, rather than being a scary day to avoid mishaps, it's actually the Day of Love for millions (Valentine's Day). Better yet, because it occurs over lunchtime, the fact can be idly mentioned to one's lunch date (for those of a nerdy disposition).
Did you write COBOL in the 70s?
Chernobyl 'not a wildlife haven' - BBC News
http://letmegooglethatforyou.com/?q=TMTOWTDI
I think I have an erection...
Hm. I read the RFC, and it seems patently insufficient when discussing necessary granularity. Clearly, time should be represented in Planck units, as this is the (currently theorized) maximum necessary resolution to describe a timepoint.
Current estimates on the age of the universe indicate that approximately 10^61 planck times have elapsed. This puts us at a present need beyond 128-bit time.
Assuming the ultimate fate of the universe is heat death with proton decay, then 256-bit time should cover the span of the life of the universe to beyond the presence of matter (~10^100 years).
For the truly pedantic, Planck-resolution time structs could be coupled with meta-size header concept from the I-TAG described in RFC2795, which would yield arbitrary representation in the case of future needs, such as if the universe does not die on schedule.
It is left as an open question to decide where the zero-point of the calendar should be fixed, given the imprecise knowledge of the birth of the universe.
Comment removed based on user account deletion
NetBSD recently cut across to 64-bit time_t and its shaken out quite a few 32 bit assumptions.
http://mail-index.netbsd.org/current-users/2009/01/05/msg007024.html
The interesting part is not converting across to 64-bit time_t, its providing compatibility so all the previously 32-bit time_t compiled binaries and library keep working (at least until 2038 :)
dev_t was converted to 64-bits at the same time (two flag days for the price of one)
It involved versioning every function/system call that uses time_t, struct timeval, struct timespec, struct itimerval, struct itimerspec, struct rusage, struct stat, dev_t, struct ppasswd, struct utmp, struct utmpx, and ensuring the system can read both old and new versions of utmpx etc...
Certain bits of code which were using time_t to hold time offsets rather than absolute values were converted to using a normal 32 bit value (a good example might be anything in space constrained boot blocks)
I expect we'll be seeing a *lot* of patches in pkgsrc as the 64bit time_t application issues are fixed...
for my birthday!
For your amusement, I put up a bit of Python code which displays the epoch time in realtime on the command-line.
Useful for counting to things! Get it at Launchpad (branch).
Alan Cox does assure us that Linux is now working on 64-bit time, and the UNIX epoch 'roll-over' would happen about the time that the sun burnt out
That's fine for the people who believed 640k ought to be enough for anyone.
Troll's remorse. The cure is to troll harder.
I made some design to celebrate 1234567890. Check out http://www.cafepress.com/1234567890m
watch -n 0.1 'python -c "from datetime import datetime; print datetime.fromtimestamp(1234567890) - datetime.now()" '
On Feb 13th it's my girl's birthday :)
I don't think she cares about UNIX time. Bummer...
osx:~ me$ date -r 1234567890
Fri Feb 13 18:31:30 EST 2009
osx:~ me$ date -r 2147483647
Mon Jan 18 22:14:07 EST 2038
osx:~ me$ date -r 2147483648
Fri Dec 13 15:45:52 EST 1901
64-bit??? really?
We're expected to use perl for such trivial tasks? I think we need a better man date.
Is there a reason no one has the intellect to go to floating point time?
When I first started playing with Java, one of the things I found appallingly silly was its handling of time. If you are going to set a new standard, it should at least be useful. The thing is too coarse to time internal events, but you can describe the age of the universe with millisecond precision.
Am I the only one who finds the fingerprints of an amateur all over this?
I'm a Programmer. That's one level above Software Engineer and one level below Engineer.
Fucking wikipedia!
Oh you sweet geeky slashdot!
Has nobody noticed that it will be Valentine's Day? (At least here in Tokyo).
There's a lot of religious controversy over the use of 'BC' and 'BCE', 'AD' and 'CE'. In these modern times, perhaps we should state all dates relative to the PE - the Posix-epoch. All the religious debates will be moot. Conservapedia will be remerged with Wikipedia, and worldwide peace will break out.
Why do we have gaydar but not virgindar?
For the same reason we have radar to detect planes and ships, sonar to detect submarines, but don't have earthdar to detect the planet earth.
Some things are too easy to find to warrant looking for.
The enemies of Democracy are
Everybody knows that a 64-bit time_t overflows in stardate year 584942000 (Using the TNG stardate system). Sheesh.
to see the local time with qore, type:
qore -X 'localtime(1234567890)'
(requires qore 0.7.0 or better) :-)
perl -e 'print localtime(1234567890) ."\n";'
Let the "." concatenate operator do it for you.
(0) kiak /home/keeling_ perl -e 'print scalar localtime(1234567890) . "\n"'
Fri Feb 13 16:31:30 2009
Once you start down the road to pedantry, ...
"Tongue tied and twisted, just an Earth bound misfit
because reading /. would cause it to explode
Quote:
This will be Friday, February 13th at 1831 and 30 seconds EST.
Why is it only estimated? I would think this would be known exactly.
So just when the whole world is plunged into chaos from the sun burning out, these guys want to compound the problems by causing widescale UNIX clock failure, too? How incredibly thoughtless.
On my 64bit system...
$ perl -e 'print scalar localtime(67767976233550799),"\n";'
Tue Dec 31 23:59:59 2147483647
$ perl -e 'print scalar localtime(67767976233550800),"\n";'
Wed Jan 1 00:00:00 -2147483648
$ perl -e 'print scalar localtime(67767976233550801),"\n";'
Wed Jan 1 00:00:01 -2147483648
$ perl -e 'print scalar localtime(67768036191694798),"\n";'
Wed Dec 31 23:59:58 -2147481749
$ perl -e 'print scalar localtime(67768036191694799),"\n";'
Wed Dec 31 23:59:59 -2147481749
$ perl -e 'print scalar localtime(67768036191694800),"\n";'
[NOTHING]
Weeeeeeee!
Not February 13th but ...
$ date -d @1234567890
Sat Feb 14 00:31:30 CET 2009
St VALENTINE'S DAY ... at about midnight ...
Kisses to you too, from Europe, Africa, Asia and Australia.
Do mean the Apple Pi from MACdonald's
Bah, i think its pretty funny anyway. But i dont know if its worth "celebrating" in the IRC-channels.. But yeah..
But the big question: Does this app use client-server synchronization to ensure it is accurate? So far all of the online countdown timers I've seen merely rely solely on the end-user's computer clock which is prone to signficant deviations from Coordinated Universal Time.
--Randall
You're right, who needs silly human standards when soon Skynet will take over and render base-10 as well as all human beings obsolescent anyway :P
--Randall
It's interesting that it took so long for the wave of interest to catch on about this date. I remember blogging about the rollover to 1,111,111,111 back in March of 2005. And I've been looking forward to February 13, 2009 ever since.
Unix Time's 1111111111 Second Countdown
It's actually quite exhilarating -- esp. for us hardcore tech geeks -- to think that we will soon witness the last significant numerological date in computer history during our lifetime (using decimal notation at least, so long as the standard for Unix time maintains signed 32-bit integers).
--Randall
You're right! I can't wait for 14 June 1933!
The Russian Mafia will mod you down just to see if the Moderate button works.
Let Ruby do it for you.
ruby -e 'puts Time.at(1234567890)'
This is Slashdot. You want to DOS your detector?
I don't understand, are we going to REALLY die or what?
I've gone through the posts (yeh, slow day), and maybe I've missed it, but has someone pondered what's so special about Jan 18, 2038?
$
$ date -d @2147483647
Mon Jan 18 19:14:07 PST 2038
$
$ date -d @2147483648
date: invalid date `@2147483648'
$
That was a close one.