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

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

epochconverter.com

170 pointsozh57 comments

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

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?

You meant internet as we know it.

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

For those that may not get the joke the 555 is a timer chip.

http://en.wikipedia.org/wiki/555_timer_IC

And for those who don't get the other joke, "555" is the Thai equivalent of "lol".

nerds.

What great pleasure this thread gave me. My Thai daughter confirmed the joke and, after a very painful explanation of bases, was laughing (tentatively) along with me.

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

A real robot would be all, 1010011011100100100111000000000

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

but why would you count time in hex?

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

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

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

1234,5678,99 scans a little better.

Happy quattuordecamegacentenial!

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.

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

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/...

<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>

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/

It's not an error, it's a design decision.

I wanted the rate of time increase to be constant every year, and I wanted the time to be universal (across all timezones). I did take leap years into account by calculating the average year length in seconds. I also wanted the calculation to be simple and independent of variations in earth's rotation speed changes, etc. So yes, over a long time, it will diverge from "years" as we know them.

The only reason I used years is to provide context, since most people have a feel for how long a year is. After that, everything is base 10.

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?

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

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

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

BSON object IDs contain a 4 byte timestamp so perhaps it'd be directly visible on those.

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.

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

https://krux.org/misc/billennium_log

Thanks for posting this.

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....

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)

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.

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-...

http://xkcd.com/1340/

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

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

"Gentlemen," he said, "I invite you to go and measure that kiosk. You will see that the length of the counter is one hundred and forty-nine centimeters-in other words, one hundred-billionth of the distance between the earth and the sun. The height at the rear, one hundred and seventy-six centimeters, divided by the width of the window, fifty-six centimeters, is 3.14. The height at the front is nineteen decimeters, equal, in other words, to the number of years of the Greek lunar cycle. The sum of the heights of the two front corners and the two rear corners is one hundred and ninety times two plus one hundred and seventy-six times two, which equals seven hundred and thirty-two, the date of the victory at Poitiers. The thickness of the counter is 3.10 centimeters, and the width of the cornice of the window is 8.8 centimeters. Replacing the numbers before the decimals by the corresponding letters of the alphabet, we obtain C for ten and H for eight, or C10H8, which is the formula for naphthalene."

"Fantastic," I said. "You did all these measurements?"

"No," Aglie said. "They were done on another kiosk, by a certain Jean-Pierre Adam. But I would assume that all lottery kiosks have more or less the same dimensions. With numbers you can do anything you like. Suppose I have the sacred number 9 and I want to get the number 1314, date of the execution of Jacques de Molay-a date dear to anyone who, like me, professes devotion to the Templar tradition of knighthood. What do I do? I multiply nine by one hundred and forty-six, the fateful day of the destruction of Carthage. How did I arrive at this? I divided thirteen hundred and fourteen by two, by three, et cetera, until I found a satisfying date. I could also have divided thirteen hundred and fourteen by 6.28, the double of 3.14, and I would have got two hundred and nine. That is the year in which Attalus I, king of Pergamon, joined the anti-Macedonian League. You see?"

"Then you don't believe in numerologies of any kind," Dio-tallevi said, disappointed.

http://en.wikipedia.org/wiki/Foucault's_Pendulum

PDF: http://www.cs.utexas.edu/users/acharya/Inputs/Books/Foucault...

For the curious: 1500000000 is in July 2017.

In case you need a CLI countdown

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

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

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

Epoch Win.

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.

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...)

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...

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.

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.

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

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

Octal then. We have 012345670000 and 012345677777 in June.

no party for the Excel people: 41772.7037037037

Windows also has it quite boring: 130444736000000000

Nobody talks about the year 30827 problem either :-(

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

numerology is not my cup of tea.

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

Reply on news.ycombinator.com