5 ms·
I'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.
by aragilar 2y ago
I'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.
- zokier 2y agoThe kernel needs to maintain leap database for POSIX time too, so that it knows when to do those double-seconds
- re 2y agoTypically operating systems don't maintain a database but instead rely on network time servers to let them know that a leap second is about to occur.
- djbusby 2y agoNot everyone has a network
- the_mitsuhiko 2y agoThe clock of machines is not reliable enough anyways most of the time. You end up having to reset them anyways.
- wodenokoto 2y agoDon’t you need that to calculate UTC as well? If you want to go back 30 seconds from 1st of January, 00:00:10 UTC, you need to know if the previous year had 60 or 61 one seconds in its last minute.
- toast0 2y agoYes, but most people are using POSIX time (intentionally or not). You don't need a database in POSIX time.
- wodenokoto 2y agoHow does posix know it’s a leap second? It needs to know one way or another. Some say it knows from a NTP server, but that’s the same as needing a database (the server has one)
- the_mitsuhiko 2y ago> How does posix know it’s a leap second? It needs to know one way or another. Unlike with TAI it does not need to know. The time on the wall is leap seconds resolved (ignore for a second how it is done). Whereas TAI keeps ticking onwards without regard of them, UTC has them cleaned up. So if your end result is that you want to show a time in local time with TAI you need to know where all the leap seconds happened. With UTC you do not need to, you will have re-synchronized your clock plenty of times since to some time source which itself has resolved the leap seconds. You do not need NTP for this. Even if you manually set your time once a year, you will use a reference source that has already dealt with the leap seconds. Since leap seconds are basically hidden historically too (they do not appear) you are good. You can always divide the seconds since 1970 down and you can pinpoint any date in the past without having to do complex leap seconds math.
- deleted 2y ago[deleted]
- FObersteiner 2y agoI guess we still like solar time a lot ;-) The point is, for date/time calculations, you need a numeric representation that increases strictly monotonically (an epoch time). If you introduce unpredictable modifications to that (leap seconds), the nice calculation falls apart, you end up with a lookup table such as the one in the IANA timezone database / TZif files (the blog post calls it the Olson library).
- groestl 2y agoThat's because a lot of people have the misconception about UTC, that it works like TAI. If you think your tool already does what you like, even though it doesn't, you're not looking for anything else.
- michaelt 2y agoThat's because for a great many purposes, doing things the way everyone else does them is an extremely big benefit. If your operating system uses UTC, your logging library uses UTC, your SSL cert issuer uses UTC, your TOTP tokens use UTC, your NTP client uses UTC, your e-mail headers use UTC, your string formatter uses UTC, your serialised data parsing libraries use UTC, everyone who sends you data uses UTC, and everyone you send data to wants to receive UTC - why swim against the current? How do I know this? Because I've tried it. Let me assure you, for every bug you avoid using TAI, you'll experience 500 bugs due to UTC/TAI confusion.