date +%s Turning 1111111111
initsix writes "Break out your party hats. According to http://www.onlineconversion.com/unix_time.htm , Unix time is supposed reach 1111111111 on
Fri, 18 Mar 2005 01:58:31 GMT
That's only 1036372537 seconds from 2^31 (ie Tue, 19 Jan 2038 03:14:08 GMT)!!"
since we brought this up, it might be interesting for everyone to read and be aware of the year 2038 bug.
(by that time, we will all have at least 64-bit systems, but still a cause for concern, read the link)
Marge, get me your address book, 4 beers, and my conversation hat.
Too bad it'll never make it to 2222222222. :-)
Looks like the next big day will be @ 1234567890 which happens to be: Fri, 13 Feb 2009 23:31:30 GMT
Guess we better celebrate this cause we'll have to wait quite awhile for the party!
In Europe and actually most parts of the world they do.
(Yes, I know that you were joking)
Think that's geeky? Puh-lease:
At 8:00 p.m. EDT (0000 GMT) April 9, 2005 +$H turns 60000!
I win!
No battles to the death are recalled. Mumpsman can hit to attack and cause brainsmashing.
00:00:00 = 12AM
The fibonacci clock always displays 11:23:58 :)
Sounds like it will be a nice Friday the 13th when this one hits. Fri, 13 Feb 2009 23:31:30 GMT is when it will be 1234567890.
'Noiropac'
http://www.2038bug.com/
its when the 32 bit timestamp that is standarly used to store time gets too large, and overflows.
Modern computers use a standard 4 byte integer for this second count. This is 31 bits, storing a value of 231. The remaining bit is the sign. This means that when the second count reaches 2147483647, it will wrap to -2147483648.
The precise date of this occurrence is Tue Jan 19 03:14:07 2038. At this time, a machine prone to this bug will show the time Fri Dec 13 20:45:52 1901, hence it is possible that the media will call this The Friday 13th Bug.
sig: Playfully doing something difficult, whether useful or not
01:12:35 is more correct, actually ^__^
No, in Europe it's
;-)
23:59:59
00:00:00
00:00:01
makes more sense, at least if you're used to it.
Have you bothered to check the of the page you're currently looking at. But note that it's a GNU extension so it might not work on, say, Solaris.
Sorry, not enough geek.
Now 0x42424242 is on Thursday, March 24, 2005 04:29:54 UTC, and depending on your timezone, that is around the beginning of Good Friday. 42 as you know represents the meaning of Life, etc., which is interesting given it occurs around Easter.
In Base2, it is 1000010010000100100001001000010,
which looks better than 1000010001110100011010111000111 or 0x423A35C7.
BTW. 42 has always been the correct answer.
0x42424242 = 1111638594 = Thu, 24 Mar 2005 04:29:54 GMT
Don't sleep too long.
Absolute-precision decimal math. No crufty repeating-binary rounding errors. Go ahead, try to store 1/10 as an absolute-precision binary number. Can't be done, because it's a repeating binary: 0001100110011100110011....
Fixed-point BCD stores it precisely. 0000000000010000
BCD is pretty popular where precision fixed-point decimal math is important...like finance. A few hundredths of a penny here, a few hundredths of a penny there....multiply times about a billion transactions a day....yeah, BCD makes more sense, except in the pure geek sense.
Welcome to the Panopticon. Used to be a prison, now it's your home.
Actually, 2147483647 is the time of the epoch, not 9999999999.