Unix time is bad and needs replacement, not UTC(z.vandillen.dev) |
Unix time is bad and needs replacement, not UTC(z.vandillen.dev) |
I like to think of it as a difference between physical time and human time.
For engineering, science, precise measurement, simulation and such using TAI is clearly the cleaner, most robust solution. But as soon as you have a humans "perception" of time as part of the system a timezone aware timestamp is required. But even then, the most common version of that ISO 8601 is flawed.
ISO 8601 only has a fixed offset, it has no concept of timezones or geolocation. Borders between timezones move, DST windows change or disappear, it has no way to account for that. What we need is an extended ISO 8601 that includes a location rather than offset. Human time is tied to a geographic location in time. I think we need something like this:
2022-11-23T08:52:02!Europe/London
or even coordinates:
2022-11-23T08:52:02!51.509865/-0.118092
1969-07-20T20:17:00!Moon/0.67416/23.47314
Physical moment in time = TAI timestamp
Human perception of a moment in time = Geolocated timestamp
For example, India, Pakistan, and China are each are in their own time zone, and (https://en.wikipedia.org/wiki/Jammu_and_Kashmir_(union_terri...) “Jammu and Kashmir is a region administered by India as a union territory and consists of the southern portion of the larger Kashmir region, which has been the subject of a dispute between India and Pakistan since 1947, and between India and China since 1962”
⇒ I expect there are events that are recorded to have happened at three different times, depending on who you ask.
https://en.wikipedia.org/wiki/List_of_territorial_disputes has many other territorial disputes, including ones between Canada and the USA (https://en.wikipedia.org/wiki/List_of_areas_disputed_by_Cana...), but most of them won’t be across time zones.
Also, there are other calendars in use than the Gregorian one. Most confusingly, some groups still use the Julian Calender.
TZ database city covers the political time based on a political centre, and is future proof for that use case.
Coordinates cover changing political centres. If a country border moves but you need to specify a time that will update with any boundary changes this is the only way. The coordinates also don't have to match the location of the event, they are specifying the "human time" reference point.
> 2022-11-23T08:52:02!Europe/London
There is a IETF standard proposal, which is very closed to getting finalised, that defines a similar format:
2022-11-23T08:52:02+01:00[Europe/London]
It's already in use by the Temporal TC39 proposal, which defines new types for working with temporal data in JavaScript.
For more fun, what does 2024-11-23T08:52:02+00:00[Europe/London] mean now, and what does it mean if the UK switches to a +1 hour offset all year round in 2023?
If i understand the proposal correctly, the actual moment in time represented by one of these is given by the time and the offset. The bit in square brackets is just metadata. The spec says:
> This document does not address extensions to the format where the semantic result is no longer a fixed timestamp that is referenced to a (past or future) UTC time.
But that result is precisely why we need this!
I don’t see why it would make sense to include points outside of Earth in that system, as I think you’re proposing.
Regarding the other part of your proposal to include locations: ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion.
1969-07-20T16:17:00!Moon/0.67416/23.47314
For other planetary bodies, or other locations in the universe the first part of the time stamp could use any other format that could be in use at that location. It doesn't have to be tied to an Earth centric system.
> ISO 8601 purposely excludes those because converting a location to a UTC offset is a political process that requires lookups for historical changes to that conversion
My point is we need a standardised interchange format what actually takes that into account as that is how humans actually operate.
I guess for multiple planets some astronomical recurring event could be used as sync source (say have "tick" be determined by some pulsar and adjusted for doppler shift)
* [1] https://warhammer40k.fandom.com/wiki/Imperial_Dating_System
The example I used was if New Years pictures were posted by a photographer in say New Zealand that was being viewed by someone in the US. Showing the US local time for that photo doesn't indicate how many minutes before or after midnight the photo was actually taken. For data transfer, ended up using strings for local date/time and location to ensure that nothing tried to interpret and transform unless explicitly intended.
2022-11-23T08:52:02!tz:423
And you can even maintain multiple versions of the database, if neccessary. Just change !tz to !tz2, !tz3, etc.
ID, well, it saves a tiny bit of space but honestly I don't think it is worth it if you're already storing info about timezone as text.
If you're storing it in binary form you can convert the name to DB entry on save/display
"Let's meet at 8am Mar 3 2023" probably shouldn't become "Let's meet at 7am Mar 3 2023" if the timezones shifts.
For example, in a booking system the timezone will be associated with the venue or the destination.
In a scheduler for a trading system certain timestamps (start, stop time etc) will be the timezone of the trading venue.
For past events (logging) UTC essentially always makes sense.
OTOH I believe that for computers, adopting something like TAI for all timestamps would probably a good thing. Re-adjusting display dates for the past where needed is much less complex wrt leap seconds than it is for time zones and DST. The conceptual simplicity of TAI and the invariants afforded by it come with the slight disadvantage that "the future can not be predicted", but we already cannot predict the future of countries changing time zones and DST dates, so we'd not be any worse off in that regard.
[Egypt](https://en.wikipedia.org/wiki/Daylight_saving_time_in_Egypt)
Intuitively it should be synchronized, but giving it more thought it is not entirely obvious why; e.g. my current local time zone is more than half an hour off of local solar time, and that isn't really a practical problem, so if UTC would be, say, five minutes off of actual solar time in Greenwich, what issues does it cause for people? Astronomy would be using specific time systems and/or adjustments anyway.
Huh, I always assumed that Unix time just ignores them and ticks forward. I get why e.g. UTC needs them but why would it make sense for Unix time to account for them given how it's defined.
Adding them into the conversion would add O(log(#leap_seconds)) complexity.
I think that continued use of leap seconds is entirely due to inertia.
Original comment:
Yes, to convert from UNIX time to UTC, you do need a list of leap seconds.
Original comment:
> The simplified definition of Unix time is that Unix time counts the amount of seconds that have passed since the first of January 1970 (which is referred to as “the epoch”, similar to the first of January of 1 AD being the epoch of the Gregorian calendar). This is of course not the complete definition, since it does not take leap seconds into consideration.
I disagree with the statement that UNIX time is not the amount of seconds since the Epoch. Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.
If we started an experiment on 23:00 and ended it on 01:00 the next day, but a leap second occured in the mean time, the experiment wasn't running for 7200 seconds, but for 7199 seconds. The leap second had nothing to do with time counting, a stopwatch would not add a second to the reading.
If we started an experiment on Epoch, the UNIX time tells us the amount of seconds this experiment has been running. If we added 86400 leap seconds in between, the experiment would count real time, not our made up time. One day wouldn't be added to the count.
As far as I understand it, that's what UNIX time is, and there's nothing wrong with that. It's a feature.
Please add your opinion.
Instead, the world needs agreement. And, wow!, an agreement among countries to simplify time keeping is an achievement!
We do not need a more complex POSIX time spec, but we need to cope with billions of written lines of code from the past that use the existing API. We need that API to be as stable as possible to reduce complexity. We need to see that no changes are needed to existing code.
We need to reduce complexity, e.g., by removing an irregular, unpredictable drift between TAI and UTC.
We do not need to rewrite legacy code to use a shiny new API, but we need to make sure that legacy code will not break, because we do not know, unfortunately, were all that code hides.
I see a lower-bound case for two: sun/Earth time and universal time. Farmers must be able to express "I will plant seeds at noon on August 29, 2329". They care about how the sun affects Earth. The worker trying to schedule a meeting is the same, because they'll want to guarantee the meeting happens during daylight. As such, I find the obsession over "always use Unix timestamps" a bit weird. Yeah, they're simple, but semantically wonky for some practical things. Everyone else, dealing with durations and time deltas unrelated to geological conditions want TAI.
For the farmer, the problem is the Gregorian calendar is deeply flawed/inaccurate, not that UTC has/had a leap second. Sun and Earth rotations are not aligned, so we cannot expect these to line up. We need year, day of year and time of day. The year is just the "number of solar turns" integer. The first and last day of the year would have to be cut up in unsavoury ways to account for misalignment. The time of day only needs to line up with Earth's rotation, but this means the speed relative TAI will need to shift as Earth is affected/slowed by the universe. (Now, I would suggest making the clock zenith based on something around the poles or leaning of the Earth axis, to end the Greenwich bias: that's pretty damn arbitrary.)
We should all re-read "the rise of worse is better" until enlightenment (https://dreamsongs.com/RiseOfWorseIsBetter.html).
So if you store two timestamps, you can't rely that the actual time that has passed between storing the two timestamps is equal to their difference, since the clock might have been slow, fast, or might have been synchronised with another clock between the recording of the two timestamps.
I think dealing with leap seconds should work in a similar way as working with other clock synchronisation issues, so I really don't see the point of adding new types of clocks in unix.
[...]
> one subgroup of one profession naming a whole time epoch was kind of pretentious.
I think that the UNIX epoch is bless contentious that the other epoch, as is not tied to a religious event. OS wars not withstanding.
Also the UNIX time was specifically designed for UNIX.
In terms of computer system design I'd say that the best is usually to convert as late as possible in a presentation layer and to use linear time internally everywhere.
It does feel very unscientific but ultimately the UTC won't get out of sync from rotation for more than a minute in my lifetime (unless desync rate increases I guess) so I don't really care
I guess what I'm really saying is that UTC-without-LS won't be UTC; rather, we'd declare that the new universal civil-time timescale is to be UTC-without-LS. You could carry on computing old-fashioned UTC after the transition; but one wouldn't generally use UTC to render civil-time for display.
Well, yeah. Except that if it's not in-spec, it's not UTC; it's something else, and it shouldn't be called UTC. If you don't change the name, you would end up unable to compare two UTC times without also knowing which version of UTC the two times were given in.
There's something about time that people seem to find very difficult to reason with. It reminds me of the arguments between whether we should use standard time all year or daylight savings time all year.
E.g. "27th March 2023 19:00 Europe/London" is not ambiguous
You certainly mean to say the UTC nerdian, right? It's defined to cut through the median of all discussions around UTC, TAI, Unix timestamps and leap seconds that occur on HN and I see no reason to move it to another forum.
Also the allowable variance between UTC and ut1 is 0.9.
Five minutes - no problem at all.
If the offset rose to 60 minutes, I know people complain bitterly twice a year when we change the clocks by an hour and they lose an hour of light for sports in the evening, or lose an hour of sleep. But with leapseconds taking ~0.5 seconds a year, that won't be a problem for a few thousand years.
[1]: Because allowing the time to drift microscopically from human perception is indistinguishable from not changing it, only that after a sufficiently long time you live in a time zone shifted by a constant, only there was never really a big event to shift it. It’s like getting old - you don’t notice it, until it’s already happened.
The OP proposal does say UTC should be used when representing time to end users, but in practice there is going to be blurry lines.
¹TBH, still confusing enough to introduce quite a bit of friction when comparing graphs etc for outages.
I feel like we should be able to easily "bundle" leap seconds into existing leap days on leap years. Make February 29th just some random number of seconds shorter or longer than, say, February 28th. Most people feel February 29ths are weird anyway, few people would probably notice when they have strange amounts of seconds in their final hour. Some software might hate it if Feb 29 23:59:56 rolls over to Mar 1 00:00:00 or much more rarely there's a Feb 29 23:59:62 (or using the existing Unix time "smearing" technique, some Feb 29 you get three or more Feb 29 23:59:59 timestamps in a row), but other than that it would 1) be on a predictable day, and 2) a day that's already a weird every 4 years except every 400 outlier that's already expected to be an edge case.
Then you don’t understand Unix time. In the first case it would return 7200, and in the second case it would count “made up time”.
UNIX time is 86400*days since epoch + seconds since midnight. It does not measure “real time”, whatever that is.
> Leap seconds never happened, they were added to UTC and UTC only in order to correct it for sunrise and sunset.
You’re apparently confusing leap seconds and DST. Leap seconds are used to compensate for minute variations in the speed at which the earth rotates (irregularities and an overall slowdown). So they serve to resynchronize atomic time (TAI) and solar time (UT1). This resynchronized version (UT1 ~ 1s) is UTC.
As far as Unix and UTC are concerned, many systems provide the option to smear the system clock over a 24h period (-12h, +12h) centered on the leap second. This avoids the discontinuity and can help avoid errors some incorrectly written programs may not be able to tolerate.
For leap smearing, see: https://developers.google.com/time/smear
Notably I don't disagree with the idea of abolishing leap seconds, but I also don't think it's entirely agreeable to have the world's timekeeping standards changed solely because of engineering needs with regards to Unix time. In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.
Sorry, but I do not agree. The current Unix time API is good enough. Especially with the leap seconds gone. We need no more complication by innovation here.
Any extensions inevitable lead to a lot of people starting to use those additional APIs, others trying to fix old code to use new APIs, and a few will start religiously fighting for the use of the new 'right' API. Software that handles time would be more diverse. And you will never live to see that old API gone anyway, because we don't know where it hides, so in the future, we would have to deal with bugs in the (mis)usage of more APIs.
> In my opinion it's somewhat silly to have the timekeeping standard of the world changed because someone at Bell labs made an unfortunate design decision regarding Unix time, rather than changing Unix time itself.
Well, maybe it is silly. But that's really irrelevant. Don't be stubborn to insist on API changes/extensions, because you think a past decision was wrong. You can't change reality anyway: the vastly bigger problem is changing Unix time, because code is written and is running in critical systems.
And because leap seconds were inserted manually anyway, we already have a solution that works: don't insert any more leap second manually.
Also note that the danger was to do something new: remove a second. That is a very dangerous experiment. E.g., the German DCF77 cannot even announce that (I think the UK and US time signals can, IIRC -- I am not sure about Japan and the other time signals). Of course you could start to postulate we need a new time signal format in Germany (and effectively half of Europe) to fix that, but that is just a much more dangerous approach.
The fact that accuracy is often not important is also crucial to my proposal of legacy Unix time, because legacy Unix time would eventually go out of sync with the rotation of the Earth just like TAI. In almost all cases this would practically be an aesthetic bug where dates in old user interfaces would be a few seconds off from the real date, and therefore not particularly harmful.
Given a TAI-based timestamp a hundred years in the future we can be pretty certain in saying "yeah it will be around lunch time" (assuming there is no major changes in the solar system that would probably have such an impact on the lives of every human that nobody would care about this event anyway).
http://git.musl-libc.org/cgit/musl/tree/src/time/timegm.c
http://git.musl-libc.org/cgit/musl/tree/src/time/__tm_to_sec...
You'll notice there is no handling or knowledge of leap seconds. (Leap years are handled, of course.)
That fork already happened with TAI. TAI was the same as universal time in 1958, and has progressed without any leap seconds. The current offset between TAI and UTC is 37 seconds. We could all agree to switch unix time to TAI, but there would be a 37 second discontinuity.
I currently work on autonomous aircraft, and we use GPS time internally for avionics. The monotonicity is very nice for correctness when developing real time code. Outside of avionics, it's very confusing for people that tend to work in UTC. I've written table based timebase converters a few times now.
Of course there are application level schedulers that use wall clock time in UTC format, and if you set the clock back your task may run twice, which is a more serious real world problem than running twice around a leap second. That is why no one who is not attached to civil time should use UTC or Unix time for short duration timer expiration in particular.
Another example is Xinjiang province, where in some towns everything is in local time, in some towns everything is in legal time, in some towns it depends on if you're Han or indigenous, and in some towns it depends on what you're doing (bus timetable vs shop opening hours).
Another example is in a very large but lightly populated part of Australia, where there local community uses a defacto timezone (Australia/Eucla) but the legal timezone is different (Australia/Perth) - it is no use saying that the polls close at 6pm and the general store closes at 6pm and coding them with the same coordinates, because one will refer to a moment 45mins after the other. Other places may have similar variations of opinions where the formal boundary of two timezones isn't really obvious - I have heard that the timezone boundary around Broken Hill is a matter of opinion as much as it is a matter of law.
The other possibility is of course that perhaps in a country like the US where timezone boundaries are relatively unstable over time because they pass through states. It's true that coordinates could be used to deal with it. But it's not obvious that this is such a systematic and regular form of variation that timestamps should use coordinates, especially considering almost any record that relates to time in a place probably already codes the place so an ad hoc migration should generally be possible. (In such a case, I would still like tagging the time with a tzid so you know for a fact whether it is premigration or a postmigration.)
We will need to encode planetary time origins, and should think about the equivalent, but I don't think that the solution to that will happen until after we need it to happen.
Take Europe/Berlin for example, the city was once divided in two parts, and is now in a country which is changing timezone twice a year. With a location, you can only communicate to use the rules valid today, not rules which were valid at some point in the past, or which are valid today, but in a different situation/context.
There’s no way to look at America/Los Angeles and know if that is California or Oregon, and if Oregon were to give up daylight savings time you’d have a problem.