11 ms·
UTC, Tai, and Unix Time (2001)
- School-Cotton 2y agoLeap seconds make no sense and we should just permanently stop doing them. It really doesn't matter if UTC drifts away from solar time by an hour every few thousand years.
- mihaic 2y agoWhy are people downvoting this comment? Genuinely curious what's not to agree with here.
- AlecSchueler 2y agoI'd guess it's because it's the usual hubris, that a software engineer's loose thoughts are worth more than the wisdom of experts in the field. It writes off all the current work as simply useless without giving any defence of that position etc.
- School-Cotton 2y agoOkay, what do you think is useful about leap seconds?
- GJim 2y agoWithout them, one can compare the eventual correction that will be required to bring our clocks back into line with the Earth (and our biology!) akin to the shift from the Julian to Gregorian calendar?
- School-Cotton 2y agoNo, it would just require time zone changes, which already happen a few times a year which we already know how to deal with (the TZ db).
- AlecSchueler 2y agoI'm not sure why you think I'm qualified to give a suitable answer to this. Did you ask the person above to explain why they aren't useful?
- School-Cotton 2y agoOkay, fair enough. I'll elaborate. Here's why I don't think they're useful: leap seconds exist to align standard time with the sun. But humans are the only ones who care about sun alignment; computers don't. And the effect of leap seconds is so microscopic that it doesn't matter to humans, especially since the alignment is inexact anyway (solar noon is never at exactly 12:00 PM on any given day except at one particular line of longitude per time zone). For getting it roughly aligned, which is what humans care about, we already have time zones with fixed, rarely-changing offsets from UTC, which I am not proposing we get rid of. Since leap seconds don't help for subjective human needs, and they _also_ don't help for computers, science, engineering etc. (if you care deeply about solar noon for some technical reason you should use something that tracks it more precisely than UTC anyway), I can't think of anything they _are_ useful for, except for saving our descendants thousands of years from now from having to change time zones when it drifts far enough to matter, which I think is a speculative and not very compelling reason. I'd happily change my opinion if I heard a good reason for keeping them, so I object to claiming that this is "hubris".
- AlecSchueler 2y agoThanks, that sounds quite reasonable to the untrained ear. Just wanted to say I didn't downvote the original comment, I was only trying to guess about how others were perceiving it.
- ttepasse 2y ago> (solar noon is never at exactly 12:00 PM on any given day except at one particular line of longitude per time zone) According to the 20. amendment the term of an US president starts at Noon, 20 Januar. Simply noon. The USA seems to interpret it as 12:00 ET and makes it ceremonial inauguration for that time, possibly also the transfer of powers. But solar noon on the steps of the Capitol seems to be at 12:18 ET, I researched back at the last inauguration. This discrepancy seems to be a great premise for a legal thriller, a political thriller, or sadly for a conspiracy theory. The latter definitely has some fertile ground. The americans should start using the Washington Monument as a solar clock for this ceremony, imo.
- bloak 2y agoIt's something people have strong opinions on. Obviously some people want to get rid of leap seconds but I personally like UTC with leap seconds. The only change I'd make is to require leap seconds to be announced several years in advance (which would require allowing a slightly bigger divergence between UTC and UT1). Computer systems should gradually migrate to using TAI internally, but a clock on the wall or a bus timetable should using something like UTC: something that, you know, stays in sync with the actual sun. Saying "oh we'll shift all the time zones around one day" isn't an acceptable solution as far as I'm concerned. And I don't believe leap minutes would work any better than leap seconds: in fact I'm fairly certain they would be a whole lot worse. Anyway, that's an explanation of my opinion. Many people will disagree with it.
- School-Cotton 2y ago> Saying "oh we'll shift all the time zones around one day" isn't an acceptable solution as far as I'm concerned. Why not? Time zones change constantly. Dealing with changing time zones is something we already know how to do easily.
- bloak 2y agoI don't think it's true that "changing time zones is something we already know how to do easily". At least not with the word "easily" in there. Time zones cause a lot of problems, which is why we don't change them constantly. And it would be nice to have a future in which time zones are changed even more infrequently rather than one in which they have to be changed to things like UTC-37:00 because they are specified in terms of a UTC that has become unmoored from the diurnal cycle of day and night. But probably the main argument against getting rid of leap seconds from UTC is that we already have TAI for anyone who wants something like UTC but without the leap seconds. In fact we already have two things that are like UTC but without the leap seconds: there's TAI and there's also GPS time, offset from TAI by 19 seconds. If that's what you want, use TAI. Or use GPS. What's the points of adding a third kind of time that is just like those two but offset by yet another small constant offset? I tend to think that there's a real use for something like UTC that stays in sync with the Earth's rotation (and thus with the diurnal cycle of day and night) and that if some coterie of bureaucrats turns UTC into another version of TAI/GPS then probably someone else will at some point have to invent another thing to replace UTC and then we'll be roughly back where we started just with extra confusing complexity. Imagine you want to specify the date and time of an international online meeting. Today you'd probably use UTC for that. But if most of the world were more than 24 hours offset from UTC then using UTC would mean specifying the "wrong" date for the meeting. You probably wouldn't want to do that so instead you'd use whatever new thing has been invented to replace UTC, something that has leap seconds or leap minutes or leap hours (or leap days?) or some other way of staying in sync with the calendar. Leap seconds seems to me like the right granularity: they're small enough to be ignored for most everyday purposes, and frequent enough that programmers can't just pretend they don't happen. (Sorry for the waffle ... I didn't intend to write that much. I should definitely care less about this seeing as whatever happens I'll be dead long before the shit hits the fan.)
- s_dev 2y agoChesterton's Fence. Why were they invented and implemented? That has to be justified before scrapping something we don't necessarily understand and a lot of programmers are just grateful we have libraries to handle this complexity for us.
- GJim 2y ago> Why were they invented and implemented? Because one cannot ignore nature? I suspect the vast majority of those programmers who have problems with leap seconds should really be using (and are unaware of) TAI.
- coldtea 2y ago>Because one cannot ignore nature? Sure we can, in computing make abstractions that ignore nature all the time. As long as there's no issue (or no big issue) with them being out of sync, we're fine. Besides there are few things natural about how we handle time, those are already big towers of abstractions on top of the movement of celestial bodies that simplify and sidestep a lot of subtleties.
- zarzavat 2y agoThe world doesn’t use TAI. If I’m making a train booking app and the train departs at 21:50 in Germany in the summer, it’s not departing at 21:50 TAI+2, it’s departing at 21:50 UTC+2. So you cannot avoid using UTC. Programmers simply deal with the world as it exists. Every single country uses UTC therefore that is how time must be represented. It is easier to remove leap seconds from UTC than it is to make all countries adopt TAI at the same instant. The concept of leap seconds can of course be preserved by defining a new time standard that isn’t called “UTC”.
- lazide 2y agoTAI is ‘a second always takes the same amount of time, and the number of seconds is always increasing’. Which is really useful in the real world when tracking/counting events every second all the time. Because leap seconds cause weird gaps or overlaps (depending on how they are happening). This doesn’t matter for pretty much anyone who doesn’t track/log/act every second all the time in a way where if a second ‘disappears’ or happens twice or takes longer on one day than on another it’s noticeable. When monitoring or tracking large scale systems, it’s a really irritating problem, which is why TAI is nice and exists in computer land. Also why it’s nice for many scientist types. For everyone else, something like UTC layered on top is more than good enough. Leap seconds are fine enough there. Same with most timezones, and PDT/PST, etc.
- aragilar 2y agoI'd argue any system that's affected by leap seconds should be using TAI, and accepting that showing users the time (or accepting user input) is going to require an up-to-date table of conversions (it's not like a leap second is any bigger of a deal than the various changes to timezones).
- mavhc 2y agoExactly, we already store and show dates and times differently due to time zones, just add seconds to that alteration too. we have tzdb, add lsdb for leap second database and we can work out the difference for any time in the past, or near future
- eyelidlessness 2y agoAt that point, why not just move leap seconds entirely into local time as part of the time zone offset? Track each time zone’s initial, current, and (inevitable for at least some locales) final leap second offset. Include it directly in the numeric expression of the offset. Freeze UTC at the initial offset, update the relevant specs to provide for this, and call it effectively “done”, where “done” is that leap seconds are an entirely human-facing, local-jurisdiction-governed concern, entirely derived from monotonically incrementing base time.
- mavhc 2y agoApart from backward compatibility, sounds like a good idea
- CryZe 2y agoYou are right, and whenever we drifted by 1 hour (or whatever is deemed too much) we can just update each time zone in the TZDB to be different by that amount of time going forward. This shifts the problem from a basically unsolved one (with how no OS properly supports TAI) to a solved one, time zones. You could even align it with a DST transition in countries that have those where you simply skip one to apply the change.
- seanhunter 2y agoWith you on this. Also (in probably increasing order of controversy): 1)daylight savings should be completely abolished. It just causes confusion. 2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything. 3)Months should be the same length. Instead of 12 months of 30, 31, 28 or sometimes 29 days, with a varying number of weeks in each month depending on the year, you have exactly 13 months of 4 weeks each (28 days). 13*28=364 which gives you an extra day "New years day" or "Christmas day" or whatever but that isn't a day of the week. If it's a leap year the day after that Christmas day is "Leap day" and it also isn't a day of the week. Then a particular date is always the same day of the week, months are all 4 weeks, quarters are exactly 3 months and 1 week each and have the same end dates every year etc. Tons of benefits. Literally the only downside people come up with when I mention it is "yeah but imagine if your birthday is now a Monday, that would SUCK!"
- darrenf 2y ago> 2)timezones should be completely abolished. They also cause confusion. If you live in California, instead of getting up at say 8am you get up at say 3pm. There is never any confusion with anyone globally about scheduling anything. But, err, "am" and "pm" refer to where the sun is in the sky. That's their literal meaning. It's useful information. Timezones are (obviously) a physical thing. Abolishing them to aide the comparatively tiny number of people worldwide who need to schedule a phone call with someone in another country is pretty bonkers IMO. Furthermore, I don't want to be booking a flight home from Australia to the UK, pick a 9am departure from SYD only to discover it's in the evening.
- seanhunter 2y agoThat meaning is a human construction. It already doesn't mean where the sun is in the sky in the current location, it means in a single specific location per timezone. We could just agree that it means "where the sun is in the sky in Greenwich, UK"[1] [1] Notionally. Obviously the sun is not often in the sky in London.
- 2y ago
- planede 2y agoThat's what TAI is for. Too bad nobody got the memo and everybody stores and communicates UTC, including computer clocks, UNIX time and NTP. There will be no more leap seconds after 2035, AFAIK.
- School-Cotton 2y agoSure. So my argument is that everything should use TAI, and local time zones should be an offset from TAI, not UTC (because local times are primarily for humans, and humans don't care about extremely slow time zone drift that leap seconds are designed to prevent). Then we can abolish UTC entirely since it serves no purpose.
- planede 2y agoThe problem isn't really about handling local time. UTC is an offset from TAI and time zones are offsets from UTC, it's overall really just an offset from TAI. Coordinating the TAI-UTC offset is not any worse than coordinating time zone offsets. The complications are around clocks, UNIX timestamp and NTP, where a steadily and monotonously increasing number would make the most sense, and that's not UTC.
- lazide 2y agoGood news, the 2038 Unixtime mess should give some impetus on cleaning this all up before then.
- fanf2 2y agoThe people in charge of leap seconds agree, and they are in the process of being abolished. The ITU World Radiocommunication Conference last year confirmed their part; the next stage is the CGPM in 2026. https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-TF.2511-2022-PDF-E.pdf https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-TF.2511-2022... https://www.itu.int/hub/publication/s-gen-news-2023-2/ https://www.itu.int/hub/publication/s-gen-news-2023-2/
- nabla9 2y agoLeap seconds are eliminated from UTC by 2035.
- School-Cotton 2y agoThat's great news.
- rssoconnor 2y agoAlso, if we don't get some calendar reform, by the year 17000, the northward (spring) equinox will be around February 23rd.
- gavinhoward 2y agoLeap seconds should be first-class instead. https://gavinhoward.com/2023/02/make-the-leap-second-first-class-an-open-letter-to-the-international-telecommunication-union/ https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
- aragilar 2y agoI'm surprised TAI isn't more widely used, given it hardcodes many of the assumptions programmers have about time. Sidenote, "Tai" in the title should be TAI.
- the_mitsuhiko 2y agoIs it really surprising? In practice people care about the time on the wall and to get that from TAI you need to maintain a leap second database.
- aragilar 2y agoThat's no different to maintaining a timezone database though, and leap seconds are more coordinated than timezone changes.
- the_mitsuhiko 2y agoI don’t need a timezone database to track UTC.
- aragilar 2y agoWhat are you using as a time source, because I guarantee that source has said mapping (from TAI or GPS time or whatever timescale it actually getting the raw data for)?
- the_mitsuhiko 2y agoUTC to a time people use / is legally mandated does not require knowledge of leap seconds as UTC takes care of it. So for all intents and purposes with UTC you can ignore that leap seconds exist. TAI to a time people use requires knowledge of all leap seconds as you otherwise end up significantly desynchronized.
- coldtea 2y agoYou do need it to do show that UTC value in local time, which most systems (except maybe server logs) eventually need. And you still need leap seconds list for UTC.
- re 2y agoNote that this page was written in 2001; the leap second situation has gotten a lot more complicated since then, with far more diverging implementations that handle it differently, and no real momentum towards widespread adoption of software that handles them "correctly" (explicitly), like the localtime() "fix" preferred by DJB. Most people seem to prefer ignoring leap seconds, pretending they don't exist by "smearing" them across the surrounding day, or even getting rid of them entirely. https://news.ycombinator.com/item?id=33658541 https://news.ycombinator.com/item?id=33658541 https://news.ycombinator.com/item?id=32226414 https://news.ycombinator.com/item?id=32226414
- planede 2y agoAt least leap seconds will be eliminated by 2035, so there is that. Computers were never good at dealing with it. Keeping computer clocks in UTC instead of TAI and rewinding it for leap seconds was always insane. The same goes for UNIX time and NTP.
- schindlabua 2y agoAre they really? I wonder why this wasn't bigger news. Anyway that's good to hear.
- GJim 2y ago> At least leap seconds will be eliminated by 2035 The arrogance of programmers who think it is possible to ignore reality to suit them :-) I suspect the reality is many are unaware of TAI which would be more than 'good enough' and make life much easier for them. EDIT: Downvotes simply for stating facts and opinions from outside the IT industry hardly prompts useful discussion!
- blueflow 2y agoNot programmers, the BIPM: https://www.bipm.org/documents/20126/64811223/Resolutions-2022.pdf/281f3160-fc56-3e63-dbf7-77b76500990f https://www.bipm.org/documents/20126/64811223/Resolutions-20... Page 24 / Resolution 4
- justin_ 2y ago> UNIX time counts the number of seconds since an ``epoch.'' This is very convenient for programs that work with time intervals: the difference between two UNIX time values is a real-time difference measured in seconds, within the accuracy of the local clock. Thousands of programmers rely on this fact. Contrary to this, since at least 2008[0], the POSIX standard (which is just paper not necessarily how real systems worked at that time) has said that "every day shall be accounted for by exactly 86400 seconds." That means that in modern systems using NTP, your Unix timestamps will be off from the expected number of TAI seconds. And yes, it means that a Unix timestamp _can repeat_ on a leap second day. There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^) EDIT: I know DJB is calling out POSIX's choices in this article, but it seems like his "definition" does diverge from what the count actually meant to a lot of people. [0] Also: "The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified." https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/basedefs/V1_chap04.html https://pubs.opengroup.org/onlinepubs/9699919799.2008edition...
- deleted 2y ago[deleted]
- zokier 2y ago> There's really no perfect way of doing things though. Should Unix time - an integer - represent the number of physical seconds since some epoch moment, or a packed encoding of a "date time" that can be quickly mapped to a calendar day? "The answer is obvious" say both sides simultaneously :^) Either way arguably POSIX time is the worst of both worlds, not being either of those. This is one of those cases where middleground compromise is worse than either option. Having datetime be just 15:17 bit structure (date:time_of_day) or more practically just int:int struct, it would be infinitely better than current POSIX time. Or just have it be plain SI seconds since epoch counter would also be better than POSIX time. Or even have both options available. There are so many better options, it is almost baffling how POSIX ended up with the worst possible one
- 2y ago
- prmoustache 2y agoUltimately, I think nobody cares anymore about POSIX.
- zzo38computer 2y agoI am not sure about that. POSIX has some benefits, and its features are commonly used; however, there are also some problems. There are other operating system specifications too, but I also wanted to make one operating system design, and I also wanted to avoid many of the problems with POSIX. I did not konw that POSIX says that 2100 is a leap year, and clearly that is no good.
- prmoustache 2y agoWhat I meam by that is 100% compatibility is not something we strive for anymore if parts/of it do not make any sense in 2024.
- deleted 2y ago[deleted]
- billpg 2y agoPick Two. A. A day is divided into a fixed number of smaller units. B. Each smaller time unit is of a fixed physical duration. C. The day cycle corresponds to the cycle of the solar day on Earth. TAI picks A and B, allowing the solar cycle to drift from the time. UTC picks B and C, adding leap seconds to keep track with Earth's solar day cycle. UT1 picks A and C, redefining the "second" to the changing rate of earth's solar day cycle.
- FabHK 2y agoGlad to see that this is being understood now. https://news.ycombinator.com/item?id=28047376 https://news.ycombinator.com/item?id=28047376 https://news.ycombinator.com/item?id=29926509 https://news.ycombinator.com/item?id=29926509
- bxparks 2y agoAnd I guess POSIX tries to pick all three, at least most of the time. It follows UTC mostly, except during leap seconds when it changes the duration of a POSIX-second to be 2 SI-seconds (positive leap second) or 0 SI-seconds (negative leap second).
- amiga386 2y agoPOSIX time_t picks A and C. 99.999998% of time_t ticks from 1970 until now have been 1 second long. 27 have been 2 seconds long. Therefore B ("each smaller time unit is of a fixed physical duration") is the variant.
- bloppe 2y agoActually, this sort-of describes "smeared UTC", which is used by some computer systems such as Google's NTP servers: https://developers.google.com/time/smear https://developers.google.com/time/smear POSIX time does not generally work that way. It may seem that way for 1-second resolution timestamps, but at higher resolutions (say millisecond resolution), the clock does not completely stop. It keeps going, jumps backward 1 second, then continues.
- vbezhenar 2y agoTAI makes sense on Earth, but when it comes to separate cosmic bodies (like Moon base), my mind does not work well enough to understand how it would work, when time physically is different from the Earth time and even might change if we're talking about accelerating rockets. And how one would design a software and protocols exchanging instant values between those bodies.
- lazide 2y agoWe’ll burn that bridge when we come to it.
- leandrod 2y agoQuite offensive its characterisation of Posix, given RMS’ involvement to make GNU viable, as far as memory serves me.
- justincredible 2y ago[dead]