top | item 7736739

Today at 16:53:20 GMT, it'll be 1400000000 in Unix time.

170 points| ozh | 12 years ago |epochconverter.com | reply

57 comments

order
[+] gilgoomesh|12 years ago|reply
That's like what? 0x53724E00? It's not even a round number. Silly humans.
[+] sytelus|12 years ago|reply
And why would you be so obsessed with round numbers? Silly pseudo-humans.
[+] ozh|12 years ago|reply
Yeah but 0x60000000 will be 14 Jan 2021 08:25:36 GMT, who knows if the internet will still exist by this time so we can celebrate?
[+] swang|12 years ago|reply
A real robot would be all, 1010011011100100100111000000000
[+] return0|12 years ago|reply
but why would you count time in hex?
[+] yread|12 years ago|reply
Hmm I still remember the party we had when it was 1234567890!
[+] baxter001|12 years ago|reply
1234,5678,99 scans a little better.
[+] rinon|12 years ago|reply
Happy quattuordecamegacentenial!
[+] awhitty|12 years ago|reply
Does anyone else get a sense of vertigo when they try out numbers like 3000000000 (January 23, 2065)? It's like it's close enough to be tangible but far enough to be scary.
[+] acqq|12 years ago|reply
Did anybody notice Sun, 09 Sep 2001 01:46:40 GMT, when it was 10000....? And why looking at decimal values, anybody calculated when we have some nice binary timestamps?
[+] cperciva|12 years ago|reply
The FreeBSD Project actually had a gigasecond bug -- the cvsup protocol (used for CVS tree replication and checkouts) transmitted time as an ASCII seconds-since-epoch value, and when September 2001 arrived, the changed string length caused a protocol sanity check to fail.
[+] alephnil|12 years ago|reply
Yes. In java at the time if you wrote a number with 9 or less digits, it would always be considered to be an int. If the number was above 1 billion (10 digits), you had to end it with an L (1000000000L), probably since it possibly could overflow an int.

We had a trial version of our software that would expire after 30 days. To make that we had a script that inserted the expiry date into the source and recompiled every night. Around 30 days before it passed 1 billion the compiler started to give an error, and the script crashed.

(It may actually have been 12->13 digits, since java use milliseconds since the epoch, but I'm not so sure this many years later)

[+] eCa|12 years ago|reply
Yes.. I ran a small service started in 2000 that saved epoch times in a varchar column. Sorting on time turned funky for a short while.
[+] settrans|12 years ago|reply
Or perhaps Fri, 13 Jul 2012 11:01:20 GMT, unix time 0x50000000? Developers using MongoDB at the time were likely to notice.
[+] trevyn|12 years ago|reply
For the curious: 1500000000 is in July 2017.
[+] adnam|12 years ago|reply
In case you need a CLI countdown

    while [ $((1400000000-$(date +%s))) -gt 0 ]; do echo $((1400000000-$(date +%s))); sleep 1; done
[+] krt|12 years ago|reply
I'm in the Mountain Time Zone (GMT-6 right now):

  #!/usr/bin/env python
  import datetime
  for when_was in xrange(0,10):
    print datetime.datetime.fromtimestamp(14 * 10**when_was)

  $ ./theabove.py
  1969-12-31 17:00:14
  1969-12-31 17:02:20
  1969-12-31 17:23:20
  1969-12-31 20:53:20
  1970-01-02 07:53:20
  1970-01-16 21:53:20
  1970-06-11 18:53:20
  1974-06-09 02:53:20
  2014-05-13 10:53:20
  2413-08-22 17:53:20

  <krt@box>:~$ python -c "import datetime;print datetime.datetime.fromtimestamp(1400000000)"
  2014-05-13 09:53:20
[+] KayEss|12 years ago|reply
Looks like you overflowed when when_was == 9, or maybe there's a time machine involved?
[+] ChiChou|12 years ago|reply
At the very first day of this year, I sent a tweet saying that Jan 01 2014 16:57:46 GMT+0800 was 1388566666666 in Unix time.
[+] userbinator|12 years ago|reply
It's amazing that there's only 24 years left until 2^31 seconds since the epoch... I'm looking forward to January 19, 2038 (provided that I'm still around by that time...)
[+] estebank|12 years ago|reply
Actually 2038 is scary because it can affect many systems that need to calculate things long (pun intended) in the future. Imagine if you take a 25 year mortgage and the backend system still uses 32bit clock_t...
[+] _xhok|12 years ago|reply
Not to be a party pooper but why is that a big deal? You'll get a neat number like that every 1,150 days or so.
[+] Sanddancer|12 years ago|reply
Because it's a neat looking number. Human brains are real good at finding patterns, and mulling over where there appears to be no patterns, hence things like the interesting number paradox ( http://en.wikipedia.org/wiki/Interesting_number_paradox ), or our puzzlement over disorders like schizophrenia, where those mechanisms break down.
[+] sebslomski|12 years ago|reply
I still remember the great 1234567890 party. We had a great time back then! (Feb 13 2009)
[+] David-A|12 years ago|reply
Octal then. We have 012345670000 and 012345677777 in June.
[+] bjoerns|12 years ago|reply
no party for the Excel people: 41772.7037037037
[+] ygra|12 years ago|reply
Windows also has it quite boring: 130444736000000000

Nobody talks about the year 30827 problem either :-(

[+] mykhal|12 years ago|reply
numerology is not my cup of tea.
[+] jacquesm|12 years ago|reply
Maybe subtle software issues introduced by people not taking into account the possibility of their software somehow living past the projected life-span is?