Live data from Hacker News

The Unix timestamp will begin with 16 this Sunday

unixtimestamp.com

81–90 of 214 posts

Re: The Unix timestamp will begin with 16 this Sunday

#81
post #21

It is going to be at 2020-09-13 12:26:40 UTC. Python: $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) GNU date (Linux): $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 BSD date (macOS, FreeBSD, OpenBSD, etc.): $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 All such dates (in UTC) until the end of the current century: $ pyth…

The datetime package is one of the best things about Python, and dare I say one of the best general purpose calendar modules ever written. It’s just so practical .

arrow (my favorite), pendulum or delorean are in my opinion much better (= easier to use, versatile, ...)

Re: The Unix timestamp will begin with 16 this Sunday

#82

Earlier quoted context omitted.

In "Deepness in the Sky" a spaceship's computer is still running on Unix time many thousands years into the future. It is generally believed that the calendar starts with the first Moon landing, and only the main character as a "programmer-archeologist" discovers a small difference between it and true Unix time 0.

Little is known about “Unix” but it is believed he or she was a charismatic spiritual leader who brought hope, healing, and comfort to countless humans on Earth and inspired numerous disciples including “BSD”, “Linux”, and “System V”.

> Little is known about “Unix” but […]

As opposed to eunuchs.

Re: The Unix timestamp will begin with 16 this Sunday

#83
post #21

It is going to be at 2020-09-13 12:26:40 UTC. Python: $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) GNU date (Linux): $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 BSD date (macOS, FreeBSD, OpenBSD, etc.): $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 All such dates (in UTC) until the end of the current century: $ pyth…

> 4_100_000_000 - 2099-12-03 16:53:20

We're going to party like it's 2099! Watch out for that Y2K+100 bug!!

Re: The Unix timestamp will begin with 16 this Sunday

#84
post #46
post #37

When we one day become a space faring civilization we will probably stop using the gregorian calendar because why would you use that on say Mars? But there really is no reason to get rid of the unix timestamp as a measure of time and this measure may stay around for a long time. This may mean that people in the future might consider 1970 as year zero where modern civilization began.

There is a very good reason to eventually abandon it: leap seconds. Unix time goes back one second whenever there is a leap second on Earth. It's extremely weird and IMHO completely ruins the purpose of a timestamp, but it's a compromise for backwards compatibility, since Unix time was created before leap seconds. This hack ensures that the number of seconds in a day remains fixed, an assumption of many systems at th…

Isn't a second just how long light takes to travel 299,792,458 m?

Also, "since Unix time was created before leap seconds." I found this interesting for the simple reason I've never spent any time thinking about Epoch vs Leap Second histories.

Re: The Unix timestamp will begin with 16 this Sunday

#85

Earlier quoted context omitted.

For those wondering, it’s roughly 1157.4 days (38 months)[0] [0]: https://www.wolframalpha.com/input/?i=1e8+seconds+in+months

The fact that it happens so consistently indicates it is some kind of conspiracy.

Like the ticking of a clock

Re: The Unix timestamp will begin with 16 this Sunday

#86
I enjoyed the lunch party we threw at work when it hit 1234567890.

I worked in Corporate IT at the time, so most of the office had no idea what we were celebrating. Somehow, neither did 80% of the tech staff. But the few of us who appreciated it really enjoyed the cake.

Re: The Unix timestamp will begin with 16 this Sunday

#87
post #21

It is going to be at 2020-09-13 12:26:40 UTC. Python: $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) GNU date (Linux): $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 BSD date (macOS, FreeBSD, OpenBSD, etc.): $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 All such dates (in UTC) until the end of the current century: $ pyth…

The datetime package is one of the best things about Python, and dare I say one of the best general purpose calendar modules ever written. It’s just so practical .

Python is great, but in this case, you could get almost identical output using bash alone:

for t in {0..4100000000..100000000}; do TZ=UTC printf "%'13d - %(%Y-%m-%d %H:%M:%S)T\n" $t $t; done

Re: The Unix timestamp will begin with 16 this Sunday

#88
post #37

When we one day become a space faring civilization we will probably stop using the gregorian calendar because why would you use that on say Mars? But there really is no reason to get rid of the unix timestamp as a measure of time and this measure may stay around for a long time. This may mean that people in the future might consider 1970 as year zero where modern civilization began.

In "Deepness in the Sky" a spaceship's computer is still running on Unix time many thousands years into the future. It is generally believed that the calendar starts with the first Moon landing, and only the main character as a "programmer-archeologist" discovers a small difference between it and true Unix time 0.

Vernor Vinge sounds like an intriguing author!

“Most years, since its inception in 1999, Vinge has been on the Free Software Foundation's selection committee for their Award for the Advancement of Free Software.”[0]

Since “A Deepness in the Sky” was written in 1999 as a prequel to “A Fire Upon the Deep” (from 1992), which do you recommend to read first?

[0] https://en.m.wikipedia.org/wiki/Vernor_Vinge

Re: The Unix timestamp will begin with 16 this Sunday

#89
post #46

Earlier quoted context omitted.

There is a very good reason to eventually abandon it: leap seconds. Unix time goes back one second whenever there is a leap second on Earth. It's extremely weird and IMHO completely ruins the purpose of a timestamp, but it's a compromise for backwards compatibility, since Unix time was created before leap seconds. This hack ensures that the number of seconds in a day remains fixed, an assumption of many systems at th…

Isn't a second just how long light takes to travel 299,792,458 m? Also, "since Unix time was created before leap seconds." I found this interesting for the simple reason I've never spent any time thinking about Epoch vs Leap Second histories.

Yes, but the point is that the UNIX timestamp doesn't count the the number of seconds elapsed since January 1, 1970. It counts 86400 seconds per day, regardless of how many seconds the day actually has (which can vary due to leap seconds).

Re: The Unix timestamp will begin with 16 this Sunday

#90
post #38
post #21

It is going to be at 2020-09-13 12:26:40 UTC. Python: $ python3 -q >>> from datetime import datetime >>> datetime.utcfromtimestamp(1_600_000_000) datetime.datetime(2020, 9, 13, 12, 26, 40) GNU date (Linux): $ date -ud @1600000000 Sun Sep 13 12:26:40 UTC 2020 BSD date (macOS, FreeBSD, OpenBSD, etc.): $ date -ur 1600000000 Sun Sep 13 12:26:40 UTC 2020 All such dates (in UTC) until the end of the current century: $ pyth…

To add, Powershell: (Get-Date "1/1/1970").AddSeconds(1600000000).ToUniversalTime() or alternatively for your local time: (Get-Date "1/1/1970").AddSeconds(1600000000).ToLocalTime()

Heh... I've run into this bug myself recently. Get-Date '...' returns a DateTime object of Unspecified kind, i.e. neither Local nor Utc. By design, such objects are interpreted as Local by ToUniversalTime() and as Utc by ToLocalTime(). They essentially assume the inverse of themselves, for better or worse.

Since the Kind property is readonly, to get the real UTC date you need:

    $naive = (Get-Date "1/1/1970").AddSeconds(1600000000)
    $local = $naive.ToLocalTime()
    $utc = $local.ToUniversalTime()
Post reply on HN