The Unix timestamp will begin with 16 this Sunday • Hacker News Board

Re: The Unix timestamp will begin with 16 this Sunday

#71

Post by peter303 » Sat, Sep 12, 2020, 5:29 PM UTC

jezze wrote: 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.

The galactic GPS would be based quasars, e.g. far away galaxies, that would pretty much appear the same positions anywhere in the Milky Way. Quasar spins are gradually slowing down. So you could tell how many light years you are from the quasar by the observed spin rates. In addition, you can determine epoch time from knowing position a spin decay rates.

Carl Sagan put a quasar GPS on a golden plaque on both Voyager probes, so future intelligences could tell where and when the Voyagers came from.

Re: The Unix timestamp will begin with 16 this Sunday

#72

Post by Dylan16807 » Sat, Sep 12, 2020, 5:32 PM UTC

m-p-3 wrote: post #60

BoppreH wrote: 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…

Or lets say we colonize a planet with a significant time dilation (ie near a supermassive blackhole), how do you deal with this? Who has the canonical time?

You'd just use some math to remove the influence of the black hole. Or for a more hands-on answer, you could have some reference beacons that are significantly further away from the black hole.

In a broad sense, the answer goes like this: Almost everything in the galaxy shares an approximate reference frame when it comes to velocity and special relativity. For general relativity and gravity, that's obviously a distortion so it doesn't count.

In the long term, to prevent very minor drift, we can use quasars as a reference.

Re: The Unix timestamp will begin with 16 this Sunday

#73

Post by lukebennett » Sat, Sep 12, 2020, 5:33 PM UTC

moralestapia wrote: post #54

fred256 wrote: post #41

I hope you are running an up-to-date Splunk version: Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data. https://docs.splunk.com/Documentation/Splunk/latest/ReleaseN...

I'm always left wondering how something like this could happen. I kind of get Y2K and stuff like overflows ... but this one? Really? Did someone put a regex like /^15... to "match" dates?

Yep, that's exactly what Splunk have done - scroll down the release notes linked to by the grandparent and the faulty regex is shown.

What's super daft is the proposed fix is only a further sticking plaster, adding support for the 16... range (and the 2020s decade) rather than all future dates. So in a couple of years a further patch will be needed...

Re: The Unix timestamp will begin with 16 this Sunday

#74

Post by ColanR » Sat, Sep 12, 2020, 5:33 PM UTC

m-p-3 wrote: post #60

BoppreH wrote: 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…

Or lets say we colonize a planet with a significant time dilation (ie near a supermassive blackhole), how do you deal with this? Who has the canonical time?

We'll probably come up with something similar to time zones once we become an interplanetary species.

"Local seconds since 1970", vs. "Static seconds since 1970".

Re: The Unix timestamp will begin with 16 this Sunday

#75

Post by Cyphase » Sat, Sep 12, 2020, 5:36 PM UTC

moralestapia wrote: post #54

fred256 wrote: post #41

I hope you are running an up-to-date Splunk version: Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data. https://docs.splunk.com/Documentation/Splunk/latest/ReleaseN...

I'm always left wondering how something like this could happen. I kind of get Y2K and stuff like overflows ... but this one? Really? Did someone put a regex like /^15... to "match" dates?

> Problem

> Beginning on January 1, 2020, un-patched Splunk platform instances will be unable to recognize timestamps from events where the date contains a two-digit year. This means data that meets this criteria will be indexed with incorrect timestamps.

> Beginning on September 13, 2020 at 12:26:39 PM Coordinated Universal Time (UTC), un-patched Splunk platform instances will be unable to recognize timestamps from events with dates that are based on Unix time, due to incorrect parsing of timestamp data.

> Impact

> ...

> The issue appears when you have configured the input source to automatically determine timestamps, ...

> There is no method to correct the timestamps after the Splunk platform has ingested the data when the problem starts. If you ingest data with an un-patched Splunk platform instance beginning on January 1, 2020, you must patch the instance and re-ingest that data for its timestamps to be correct.

> Cause

> The Splunk platform input processor uses a file called datetime.xml to help the processor correctly determine timestamps based on incoming data. The file uses regular expressions to extract many different types of dates and timestamps from incoming data.

> On un-patched Splunk platform instances, the file supports the extraction of two-digit years of "19", that is, up to December 31, 2019. Beginning on January 1, 2020, these un-patched instances will mistakenly treat incoming data as having an invalid timestamp year, and could either add timestamps using the current year, or misinterpret the date incorrectly and add a timestamp with the misinterpreted date.

Re: The Unix timestamp will begin with 16 this Sunday

#76

Post by LeoPanthera » Sat, Sep 12, 2020, 5:54 PM UTC

susam wrote: 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…

Omit the "u" to see the result in local time, not UTC.

Re: The Unix timestamp will begin with 16 this Sunday

#77

Post by ericbarrett » Sat, Sep 12, 2020, 5:55 PM UTC

susam wrote: 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.

Re: The Unix timestamp will begin with 16 this Sunday

#78

Post by willvarfar » Sat, Sep 12, 2020, 5:57 PM UTC

Tangentially related, last week I made a tiny one-file Java lib for working with Unix timestamps in milliseconds (as returned by System.currentTimeMillis() etc). It’s several orders of magnitude faster that Java’s time api!

https://github.com/williame/TimeMillis

It’s probably not as fast as it could be: all speed ups and improvements welcome!

Re: The Unix timestamp will begin with 16 this Sunday

#79

Post by robk » Sat, Sep 12, 2020, 6:15 PM UTC

susam wrote: 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…

It made me feel better doing the math I'm likely to be alive for 3,000,000,000

Re: The Unix timestamp will begin with 16 this Sunday

#80

Post by kazagistar » Sat, Sep 12, 2020, 6:15 PM UTC

komali2 wrote: post #58

remram wrote: post #47

Earlier quoted context omitted.

You mean that from a remote place or fast-moving ship, the time on Earth would appear to go at a different speed? So local time would not just have a constant offset?

Yea, but if we're going to use a "number of seconds since ..." Type system like Unix time, SOMEONE has to be the origin point, so I don't think this is a knock against Unix time.

Its unfortunate to use an accelerating reference (earth rotating sun, sun rotating galaxy, galaxy intermixing with andromeda) because it requires you to awkwardly keep track of the astronomy of earth for timekeeping. Instead, you would want a standardized reference time frame, say, "unix time assuming earth in 1970 never experienced any acceleratiom or dilation" and then everyone, including earth people, would track their acceleration and dilation offsets to be able to compare time when meeting or convert signal timestamps from any source back to their local time.