Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
s...@eskimo.com said: > There's a path via which NTP or some other external program can set it, but I > haven't seen an NTP server in the wild that knows how and is configured to do > so. (I'd love to be proved wrong on this, though.) ntpd has an option to read a leap file. That sets the TAI offset and also tells the kernel when the next leap will happen if one is scheduled. ftp://ftp.nist.gov/pub/time/leap-seconds.list https://hpiers.obspm.fr/iers/bul/bulc/ntp/ https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Systems that need a leap second free time scale these days seem to be using GPS time instead of TAI. It seems to be rather popular in the financial industry. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
On 8/8/19 4:24 AM, Greg Troxel wrote: The POSIX specification says that unix time (what gettimeofday returns, the numbers that are stored in the filesystem for mod times) is a strange version of UTC, where it's expressed in seconds since the epoch as if there were no leap seconds. which is essentially a time scale that is TAI with a fixed offset of the TAI time corresponding to "tick zero". https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_20 So you should be aware that keeping your system clock in TAI is fighting city hall. If only the first few nerds who wrote UNIX were time nuts, things might have been different :-) Indeed, and I shout/type/think bad things about them periodically, such as now. The usual reason to want to use TAI for the system clock is to avoid leap seconds in the local timescale, to get "t2-t1 is elapsed time, plus to rail against the original decision to use sort-of-UTC instead of TAI. Exactly. As I understand it, using TAI requires the timezone mechanism to be extended to handle leap seconds, basically converting TAI to UTC before converting UTC to lcoal time. Yep - and how hard is that? the conversions to local time are byzantine enough, varying from place to place and year to year. In the US, the candy industry has a big effect on the transition times. It also requires things like ntpd/chrony to convert the wire-format timestamps (which in NTP are similar to Unix timeval, but with a different epoch) to from/TAI. I have the impression the above two are worked out, by time nuts who have gone before you. There are also other uses of time, in wire protocols, and in databases, and I suspect those would need special handling and that some of that special handling is missing. For times you don't mind being wrong by 30s, it may not matter - but most people don't notice leap seconds, and the idea that a time nut who wants to use TAI to fix leap second discontinuities is ok with blurring TAI and UTC in other places does not compute. discontinuities in a time scale are a pain. As you say, for human reading, where you just want to make sure you show up for dinner on time, nobody cares about the leap second, or fractional millisecond offsets. For situations where milliseconds matter (High frequency trading, for instance), then time scale choice, and how it is implemented, is important. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
On 8/8/19 2:51 AM, Tim Dunker wrote: Dear Ralph I keep all our GNU/Linux machines on UTC (i.e., <>). Our timezone is off by one or two hours, but the actual offset does not matter to me. What matters to me is to have all systems using the same timezone, and for our purposes, nobody cares about our local time. Can the same thing be done in practice with TAI? Yes, I guess so, but you have to go to much greater lengths to get it to work. Red Hat has a nice article [1] on their website on leap second handling in the kernel and clients like ntpd and chronyd. You have probably also read a thread on superuser.com [2], where ntpd and chronyd problems are discussed. TAI would probably be the more logical way to store and do calculations with time, only including leap seconds when formatting time for human consumption. Or am I wrong in this? Maybe I am just dumb, but I personally see no advantage of doing this extra work. Is TAI a logical choice while UTC is not? Hm. We know when a leap second is inserted (or removed, even though it has yet to happen), so for all human-readable stuff (log files, data analysis, ...), I am happy to have everything on UTC. That being said, TAI is very nice if you acquire data continuously and leap second handling is not ideal on the instrument in question. But as long as you do not do that, it seems easier to me to go the other way around: keep everything on UTC, but convert to TAI when necessary. If you're setting up events that have to occur at some time in the future, relative to a time now, TAI is your friend, because you don't have to worry about crossing a leapsecond boundary. If it's June 29th, and I want to schedule an event to occur on July 3rd, exactly 400,000 seconds from now, it's nice to not have to worry about whether anyone is counting leap seconds. Likewise, if you are processing a stream of data, it's nice to be able to just subtract time1 from time2, and not have to worry if the timedelta needs an adjustment. Historically, in the space business, spacecraft measured their own time in terms of clock ticks, and you'd uplink commands in terms of clock ticks, for that spacecraft. Some folks on the ground keep track of time correlation, and adjusting for tick rates, earth received time, etc. so that data collections, trajectory correction burns, etc. all happen at the right time. Fine if your one spacecraft is Cassini and you have a team of dozens to manage it. Or even a Mars rover and a Mars Orbiter that need to communicate with each other - there's folks on the ground who can figure it out, and you can manually avoid doing transfers or activities across a leap second. We actually did this with ops on SCaN Testbed on ISS - we shut down before midnight UTC, waited until around 00:30 UTC, just to make sure the leap second had propagated around, including any "smearing", and started ops back up to finish the experiment. Not so fine if you have 100 spacecraft, each with different clocks, communication schedules, etc. Do the calculations and data storage/retrieval in a monotonically increasing, constant rate (or at least continuous rate for the first couple derivatives) time scale, and convert to whatever you want for human interpretation. This is especially true if there's more than one system involved, because then you don't have to worry if the two systems agree on their interpretations. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Ralph Aichinger wrote: > TAI would probably be the more logical way to store and do > calculations with time, only including leap seconds when > formatting time for human consumption. Indeed. Just about everybody I know who's studied this issue carefully has come to more or less the same conclusion. It would work much, much better than UTC -- except we're basically stuck with UTC. The wonderful thing about TAI is that since it's truly monotonic, it is much, much easier to represent and manipulate than is a discontinuous timescale like UTC. In fact, you can immediately see how useful a monotonic timescale is by observing that POSIX has decreed that UTC is one. Except of course that it isn't, which leads to *the* glaringly fundamental but nearly irresolvable issue when it comes to keeping truly correct time, and in particular handling leap seconds, on Unix-like operating systems. > There is a CLOCK_TAI on Linux, but what will happen if I use it > as my default clock? First of all, there's no current way of making CLOCK_TAI the "default clock". Deep down inside, the primary, master clock on any Unix or Linux system is supposed to keep UTC. When you call clock_gettime to fetch CLOCK_TAI or any of the other times, they're generally algorithmically derived from the master clock, i.e. from UTC. And even given that it's a derived clock, the support for CLOCK_TAI is, so far as I've been able to investigate it, still somewhat incomplete. When the system boots up, it has no way of knowing what the TAI-UTC offset is, so of course it starts out as 0. There's a path via which NTP or some other external program can set it, but I haven't seen an NTP server in the wild that knows how and is configured to do so. (I'd love to be proved wrong on this, though.) Furthermore, if nothing sets the TAI-UTC offset, and if a leap second occurs, the kernel blindly increments the TAI-UTC offset to 1, which is just wrong. One appealing possibility would be to redefine the kernel's master clock to be TAI, and to derive all other clocks (including CLOCK_REALTIME, which is the primary fetchable UTC time) from it. Again, the big difficulty (besides the amount of rewriting involved) is the startup sequence. There's not a good, guaranteed way for a newly-booted machine to learn what the current TAI time, and TAI-UTC offset, are. Just about every scrap of public infrastructure devoted to timekeeping distributes UTC, not TAI. (There's much more that could be said about this; I'll provide some references at the end.) And then there's the possibility of *not* rewriting any kernel code, declaring that it deals in nothing but TAI, and shoving all the squishy aspects of leap seconds and UTC conversion to user mode. But you've still got the startup problem, *and* you've got the problem that there are several places in the kernel that actually need proper UTC. One is so that you can set the modification timestamps on files correctly. And I believe there are a number of other kernel daemons and drivers that need UTC so that they can properly implement various networking protocols, such as those involved with streaming video. (I'm fuzzy on the details, but I'm reasonably sure those other kernel-level UTC consumers exist.) But if you do want to throw caution to the winds, run your kernel on TAI, and punt the UTC conversion to user mode, there's some nicely mature code already built in to every Unix and Linux system that will do most of the work for you, and it's been around since the 1990s (or maybe even the 1980s, I'm not sure). This is based on the so-called "right" timezones, which introduce the TAI-UTC offset when a conversion from time_t to struct tm is performed, i.e. at the exact same spot that timezone offsets and DST corrections are applied, which is arguably precisely the right place to do it. The requisite leap second tables are part of the zone files, the same ones that contain all of the timezone and DST information, and are regularly updated. You can read about this at: https://www.ucolick.org/~sla/leapsecs/right+gps.html (Actually, that page describes a variation on the "right" scheme, using GPS time instead of TAI.) Unfortunately, virtually no one uses the "right" zones, in part because of the boot problem, in part because of the filesystem timestamp problem, and in general because the scheme basically violates the POSIX standard up, down, and sideways. These issues have been discussed at length on, as you can imagine, the LEAPSECS and TZ lists. Here are two representative messages I had handy: https://pairlist6.pair.net/pipermail/leapsecs/2016-July/006251.html https://mm.icann.org/pipermail/tz/2004-March/012305.html ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
On 8/8/19 1:30 AM, Ralph Aichinger wrote: Hi! Another newbie type question: When thinking about how computers represent time, TAI would probably be the more logical way to store and do calculations with time, only including leap seconds when formatting time for human consumption. Or am I wrong in this? No, you are correct - that is the *right* way to do it, but sadly, there are all kinds of gyrations that people go through because they want to work in UTC (or GMT or Central Daylight Time) as the native time. Even in the space business, which should know better... There is a CLOCK_TAI on Linux, but what will happen if I use it as my default clock? Will stuff break in subtle ways (older programs, whatever)? I've read that chrony does not initialize it correctly, which makes me suspect this stuff is not quite ready for prime time? Does anyone on this list have Linux systems that are "TAI only", e.g. writing their system logs with TAI timestamps, etc.? There are certainly people keeping all their clock settings to UTC/GMT even when their local timezone is quite a bit off. Can the same thing be done in practice with TAI? /ralph ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there. ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Ralph Aichinger writes: > Another newbie type question: When thinking about how computers > represent time, TAI would probably be the more logical way to store > and do calculations with time, only including leap seconds when > formatting time for human consumption. Or am I wrong in this? There are two questions buried there. One is "would it have been a better design decision to use TAI", and the other is "given the way the world is, is it better for me to use TAI", to which I would reply "probably" (but that's an academic question) and "probably not". > There are certainly people keeping all their clock settings to UTC/GMT > even when their local timezone is quite a bit off. I don't follow this sentence at all. UTC and local time are not "off"; they are just different representations of the same thing (off implies an error). I'll take that as colloquial language as someone might say something like "EDT is 4 hours off from UTC. The second part is that all UNIX-like systems keep their system clocks in almost-UTC (see below), and have since the beginning, or at least before UNIX escaped from the lab. I remember a UTC (perhaps mislabeled GMT) system clock on Sixth Edition Unix in 1977. The POSIX specification says that unix time (what gettimeofday returns, the numbers that are stored in the filesystem for mod times) is a strange version of UTC, where it's expressed in seconds since the epoch as if there were no leap seconds. https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html#tag_21_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap03.html#tag_21_03_00_20 So you should be aware that keeping your system clock in TAI is fighting city hall. If only the first few nerds who wrote UNIX were time nuts, things might have been different :-) The usual reason to want to use TAI for the system clock is to avoid leap seconds in the local timescale, to get "t2-t1 is elapsed time, plus to rail against the original decision to use sort-of-UTC instead of TAI. As I understand it, using TAI requires the timezone mechanism to be extended to handle leap seconds, basically converting TAI to UTC before converting UTC to lcoal time. It also requires things like ntpd/chrony to convert the wire-format timestamps (which in NTP are similar to Unix timeval, but with a different epoch) to from/TAI. I have the impression the above two are worked out, by time nuts who have gone before you. There are also other uses of time, in wire protocols, and in databases, and I suspect those would need special handling and that some of that special handling is missing. For times you don't mind being wrong by 30s, it may not matter - but most people don't notice leap seconds, and the idea that a time nut who wants to use TAI to fix leap second discontinuities is ok with blurring TAI and UTC in other places does not compute. Are you just wondering, or trying to build a data recorder for use during leap seconds? ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
Re: [time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Dear Ralph I keep all our GNU/Linux machines on UTC (i.e., <>). Our timezone is off by one or two hours, but the actual offset does not matter to me. What matters to me is to have all systems using the same timezone, and for our purposes, nobody cares about our local time. >> Can the same thing be done in practice with TAI? Yes, I guess so, but you have to go to much greater lengths to get it to work. Red Hat has a nice article [1] on their website on leap second handling in the kernel and clients like ntpd and chronyd. You have probably also read a thread on superuser.com [2], where ntpd and chronyd problems are discussed. >> TAI would probably be the more logical way to store and do calculations with time, only including leap seconds when formatting time for human consumption. Or am I wrong in this? Maybe I am just dumb, but I personally see no advantage of doing this extra work. Is TAI a logical choice while UTC is not? Hm. We know when a leap second is inserted (or removed, even though it has yet to happen), so for all human-readable stuff (log files, data analysis, ...), I am happy to have everything on UTC. That being said, TAI is very nice if you acquire data continuously and leap second handling is not ideal on the instrument in question. But as long as you do not do that, it seems easier to me to go the other way around: keep everything on UTC, but convert to TAI when necessary. Cheers Tim [1] https://access.redhat.com/articles/15145 [2] https://superuser.com/questions/1156693/is-there-a-way-of-getting-correct-clock-tai-on-linux signature.asc Description: OpenPGP digital signature ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
[time-nuts] Is using TAI in Unix/Linux system clocks working in 2019?
Hi! Another newbie type question: When thinking about how computers represent time, TAI would probably be the more logical way to store and do calculations with time, only including leap seconds when formatting time for human consumption. Or am I wrong in this? There is a CLOCK_TAI on Linux, but what will happen if I use it as my default clock? Will stuff break in subtle ways (older programs, whatever)? I've read that chrony does not initialize it correctly, which makes me suspect this stuff is not quite ready for prime time? Does anyone on this list have Linux systems that are "TAI only", e.g. writing their system logs with TAI timestamps, etc.? There are certainly people keeping all their clock settings to UTC/GMT even when their local timezone is quite a bit off. Can the same thing be done in practice with TAI? /ralph ___ time-nuts mailing list -- time-nuts@lists.febo.com To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
