7 ms·
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 wei
by BoppreH 6y ago
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 the time.
- JdeBP 6y agoLeap seconds were introduced in 1972. The time_t that you are thinking of was invented somewhere around 1974, according to Unix historians. Ironically, your kernel measures TAI time perfectly happily if unmolested, as that always ticks once for every SI second (ignoring oscillator drift). No slewing. No smearing. No stepping.
- iso1210 6y agoWhy would someone on Mars, or an asteroid, or orbiting venus, care about leap seconds on earth? Number of seconds since a given time seems fine until we're travelling significantly outside of a common reference plane.
- beagle3 6y agoThat’s exactly why op said we should abandon Unix time. The “who cares about leap seconds” standards is called TAI, and the difference between TAI and Unix time changes every time a leap second is introduced. Unix time decrees every day has exactly 86400 seconds. But the introduction of leap seconds means that While most days have 86400, some earth days have 86401 seconds and potentially there could also be days with 86399 TAI makes sense everywhere, Unix time only on earth.
- BoppreH 6y agoBecause that's not how Unix time is defined. The leap second hack is hardcoded into it: Unix time is [...] the number of seconds that have elapsed since the Unix epoch, minus leap seconds. - Wikipedia If you are on Mars you'll have to update your computer time every ~6 months when Earth release a new table of leap seconds caused by e.g. earthquakes.
- m-p-3 6y agoOr 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?
- Dylan16807 6y agoYou'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.
- ColanR 6y agoWe'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".
- flopunctro 6y agoAFAIK, there is no canonical time in relativity. There is the "local time", which is what your wristwatch shows, and the "time in place X", where X can be Earth, Mars, or some spaceship. These times might not be in sync, and they might even be distorted. Because, if place X is moving relative to you at a significant percentage of lightspeed, their seconds will be longer. Also, the further X is, the blurrier the concept of simultaneity becomes. Which makes the question "what time is it _now_ in place X" moot :)
- numpad0 6y agoIf relativity don’t allow time travel doesn’t it make time canonical? A clock on Earth from telescope might look jumpy but only in forward direction after compensating for distance I think
- 6y ago
- Dylan16807 6y agoOr we just pretend they never happened.
- dylan604 6y agoIsn'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.
- sltkr 6y agoYes, 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).
- bitpow 6y agoIs this accurate though? Isn’t the number of seconds since 1970 absolute, and it’s up to the library generating the Gregorian date to take into account leap seconds? I suppose if these libraries are not taking into account leap seconds, then the actual rollover will be a few seconds earlier (or later?) than what we think.
- fanf2 6y agoSee the definition of seconds since the epoch at https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799.2018edition... tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400
- JdeBP 6y agoYour time_t isn't the true number of SI seconds since the Epoch. It's that number, mucked around 27 times so far. Instead of leaving their kernels to count one tick per SI second (ignoring oscillator drift) many people slew, step, or smear their seconds count every time that there is a leap second. Go and read about "right" versus "posix" timezones. * https://unix.stackexchange.com/a/294715/5132 https://unix.stackexchange.com/a/294715/5132
- 6y ago