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

http://www.epochconverter.com/

by ozh • 12 years ago

170 57 12 years ago

acqq• 12 years ago

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?

khc• 12 years ago

apparently: http://blog.jdlh.com/en/2009/02/12/1234567890_day/1000000000...

settrans• 12 years ago

Or perhaps Fri, 13 Jul 2012 11:01:20 GMT, unix time 0x50000000? Developers using MongoDB at the time were likely to notice.

stingraycharles• 12 years ago

Could you elaborate? I couldn't find anything about that timestamp in relation to MongoDB.

cperciva• 12 years ago

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.

mrrazz• 12 years ago

Yes, I remember it fondly, celebrating the 'billennium' on IRC:

https://krux.org/misc/billennium_log

thret• 12 years ago

Thanks for posting this.

slyall• 12 years ago

Openldap got hit by the billennium bug. I remember because we told our Noc to keep an eye open (Sunday afternoon where we were) and we started getting alerts that all LDAP replication was broken.

http://www.openldap.org/lists/openldap-bugs/200109/msg00052....

alephnil• 12 years ago

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

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.

dribnet• 12 years ago

Yes, this was on the radar then as Y2k was still fresh in everyone's memory.

[1] "S1B coming" http://tech.slashdot.org/story/01/04/17/1915221/the-quickly-...

[2] "Any Billennium Bugs?" http://tech.slashdot.org/story/01/09/10/0353238/billenniums-...

trevyn• 12 years ago

For the curious: 1500000000 is in July 2017.

rinon• 12 years ago

Happy quattuordecamegacentenial!

gilgoomesh• 12 years ago

That's like what? 0x53724E00? It's not even a round number. Silly humans.

ozh2• 12 years ago

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?

yiedyie• 12 years ago

You meant internet as we know it.

kachnuv_ocasek• 12 years ago

0x55555555 is in a year and two days. Tangible enough?

kalleboo• 12 years ago

0x60000000 will be fine. The internet won't end until at least 0x7FFFFFFF!

swang• 12 years ago

A real robot would be all, 1010011011100100100111000000000

shurcooL3• 12 years ago

Why would a real robot be using ascii characters 48 and 49?

return0• 12 years ago

but why would you count time in hex?

mykhal2• 12 years ago

why not? why are you dividing a day into 24 parts, and them into 60 parts, and them again as well?

sytelus• 12 years ago

And why would you be so obsessed with round numbers? Silly pseudo-humans.

ChiChou• 12 years ago

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.

awhitty• 12 years ago

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.

ozh2• 12 years ago

Yeah, unless http://en.wikipedia.org/wiki/Year_2038_problem

shurcooL3• 12 years ago

I often glance at a floating-point year clock that shows time is passing in the context of a year [1].

It helps me get back on track of being productive and stay true to my goals, when seeing time fly by in such a way...

[1] https://dl.dropboxusercontent.com/u/8554242/dmitri/projects/...

zwegner• 12 years ago

<super-pedantic-mode>That's actually fixed-point, since the decimal point is always in the same place, right after the year.</super-pedantic-mode>

ingenter• 12 years ago

Interestingly, there is an error in your code: number of seconds in a year is not constant, so you might get next year before a new year. Here's a fixed version: http://jsfiddle.net/r8txd/4/show/

yread• 12 years ago

Hmm I still remember the party we had when it was 1234567890!

baxter001• 12 years ago

1234,5678,99 scans a little better.

richbradshaw• 12 years ago

Epoch Win.

callesgg• 12 years ago

http://xkcd.com/1340/

sirtel• 12 years ago

Could you please explain more, I don't get this.

ronaldx• 12 years ago

If serious: "exciting" dates, such as 5/8/13 (Fibonacci numbers), happen all the time. Randall at XKCD is mocking those who find this exciting.

Further explanation: http://www.explainxkcd.com/wiki/index.php/1340

userbinator• 12 years ago

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

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

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

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.

lifeisstillgood• 12 years ago

Woaa - schizophrenia and pattern matching? Can you elaborate that sounds interesting !

krt• 12 years ago

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

Looks like you overflowed when when_was == 9, or maybe there's a time machine involved?

bjoerns• 12 years ago

no party for the Excel people: 41772.7037037037

ygra• 12 years ago

Windows also has it quite boring: 130444736000000000

Nobody talks about the year 30827 problem either :-(

adamnemecek• 12 years ago

Maybe by that time people will have finally upgraded from XP. But maybe I'm too naive.

sebslomski• 12 years ago

I still remember the great 1234567890 party. We had a great time back then! (Feb 13 2009)

mykhal2• 12 years ago

numerology is not my cup of tea.

jacquesm• 12 years ago

Maybe subtle software issues introduced by people not taking into account the possibility of their software somehow living past the projected life-span is?

adnam• 12 years ago

In case you need a CLI countdown

    while [ $((1400000000-$(date +%s))) -gt 0 ]; do echo $((1400000000-$(date +%s))); sleep 1; done

David-A• 12 years ago

Octal then. We have 012345670000 and 012345677777 in June.

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

Related Stories