Re: [LEAPSECS] Running on TAI
On Fri, Jan 18, 2019 at 1:35 AM Martin Burnicki wrote: > Steve Allen wrote: > > On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: > >> Hm, maybe that was originally the case. I wonder whether the folks who > >> wrote the text just had UTC in mind when they "invented" time_t. > > > > The best insight into the POSIX committee was posted on LEAPSECS in > > 2003 > > https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html > > Very interesting. Thanks for the pointer! > I've had people report similar discussions or histories related from the committee in real life as well.. :( > > Not clear in that posting was that Arthur David Olson's timezone code > > for Unix systems already contained the code written by Bradley White > > which allows time_t to count every second in the radio broadcast time > > scale and handle leap seconds. POSIX committee members knew that and > > decided to disregard it with words that actually prevented system > > designers from adopting a more correct scheme. > > > >> So IMO this clearly says that time_t has to be interpreted depending on > >> the context, and must not necessarily hold exclusively UTC numbers of > >> second. > > > > The tricky part comes when software on one system exchanges values of > > time_t with another system that believes time_t has a different value. > > Yes, but that's basically what I said: It depends on the context (or > maybe a different word would be more appropriate than "context"), but > not on the data type. > > It's even the same if you look at different struct timespecs taken on > the same system, but with different clock IDs. From the data type alone > you don't know how to interpret this correctly. > And that's ultimately my point as well. time_t is defined, by POSIX, only for certain clocks. All other clocks are aggressively undefined by the standard. You can't take the time_t's from a timespec returned from any clock other than CLOCK_REALTIME and be assured of getting meaningful results for a call to localtime() or gmtime(), for example. clock_gettime(CLOCK_UPTIME), for example, returns time in an epoch that's not really knowable (elapsed time since the system booted) without other dynamic pieces of data. Hence my comments that time_t is very narrowly standardized, though people often use it for other things. It's important to constrain arguments about what POSIX does and does not provide to what is standardized. The whole leap second fiasco in POSIX revolves around how stupidly it is defined in the standard (where stupidly here means making the actual time standard impossible to implement, but also a nasty moral judgement on my part about how the supposedly "good enough" definition has failed the test of time). > >> I think a good solution would be to have a structure that contains a > >> time_t value plus at least one flag that indicates the leap second > >> status, or a field with TAI index. It would be even better to have such > >> additional information available with struct timespec, so an application > >> can tell if the time stamp is inside a leap second, or not. > > > > I think that the entire infrastructure should recognize the notion of > > needing two kinds of time: precision seconds and civil days. That is > > what the astronomy community had understood and promoted since before > > 1950. > > I fully agree. From what I've read there are some programming > environments (Java, Python, ...) that provide individual workarounds for > the limitations of the OS, but I think you run into trouble again if you > have to exchange timestamped data between applications that have been > developed using different build environments. > Unfortunately, I think that's a rat-hole that's as big or bigger than the timezone rathole. Data containing times in the past generally isn't in a uniform timescale used today, so the older you get, the more complicated things become. And each discipline has differing notions of time. Astronomers have one, but that differs by observatory if you get old enough (mostly the same, but all relative to some local time). People have others. Lots of others. Many notions of local time existed, most loosely based on the sun, but not exactly Solar Time for all users (eg Big Ben set the time for the area around it, and other clocks in London were set to Big Ben's chimes and others to chimes of other clocks set to Big Ben's clocks, so that you had only a loose notion of a translation to a universal time from times in historical records). Some stuff would be easy to do, but it grows quickly as different notions of time would have to be added to accommodate more users of time throughout history. > > That is the hard part. It is the part that technical folks punted on > > doing during the 1960s because it would have required explaining the > > need for two kinds of time to bureaucrats and legislators and waiting > > for them to change laws and regulations. Instead they chose to act > > quickly
Re: [LEAPSECS] Running on TAI
Tempus fudgit anyone? On 18/01/2019 01:40, Daniel R. Tobias wrote: On 17 Jan 2019 at 15:57, Brooks Harris wrote: In private discussion with one member of that committee on that topic it was said "... but the time people would just not stop arguing!". Funny how everybody knows what time is but can't agree on what time is. The music group Chicago discussed this situation decades ago... https://www.youtube.com/watch?v=7uy0ldI_1HA ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
Martin Burnicki wrote: > It's even the same if you look at different struct timespecs taken on > the same system, but with different clock IDs. From the data type alone > you don't know how to interpret this correctly. We've got waaay too many time structures already, but if anyone's in a position to standardize new ones and have them taken seriously: a tagged struct timespec, that carries its clock ID along with it, would be huge. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
Steve Allen wrote: > On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: >> Hm, maybe that was originally the case. I wonder whether the folks who >> wrote the text just had UTC in mind when they "invented" time_t. > > The best insight into the POSIX committee was posted on LEAPSECS in > 2003 > https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html Very interesting. Thanks for the pointer! > Not clear in that posting was that Arthur David Olson's timezone code > for Unix systems already contained the code written by Bradley White > which allows time_t to count every second in the radio broadcast time > scale and handle leap seconds. POSIX committee members knew that and > decided to disregard it with words that actually prevented system > designers from adopting a more correct scheme. > >> So IMO this clearly says that time_t has to be interpreted depending on >> the context, and must not necessarily hold exclusively UTC numbers of >> second. > > The tricky part comes when software on one system exchanges values of > time_t with another system that believes time_t has a different value. Yes, but that's basically what I said: It depends on the context (or maybe a different word would be more appropriate than "context"), but not on the data type. It's even the same if you look at different struct timespecs taken on the same system, but with different clock IDs. From the data type alone you don't know how to interpret this correctly. >> I think a good solution would be to have a structure that contains a >> time_t value plus at least one flag that indicates the leap second >> status, or a field with TAI index. It would be even better to have such >> additional information available with struct timespec, so an application >> can tell if the time stamp is inside a leap second, or not. > > I think that the entire infrastructure should recognize the notion of > needing two kinds of time: precision seconds and civil days. That is > what the astronomy community had understood and promoted since before > 1950. I fully agree. From what I've read there are some programming environments (Java, Python, ...) that provide individual workarounds for the limitations of the OS, but I think you run into trouble again if you have to exchange timestamped data between applications that have been developed using different build environments. > That is the hard part. It is the part that technical folks punted on > doing during the 1960s because it would have required explaining the > need for two kinds of time to bureaucrats and legislators and waiting > for them to change laws and regulations. Instead they chose to act > quickly and implement something controversial and technically barren. > > The rest of the technical parts needed for the notion of two kinds of > time have been discussed here before. The underlying time scale used > for radio broadcasts and operations by any kind of machine should be > purely atomic. The counting of calendar days and setting of civil > clocks should be calculated using an offset from the underlying atomic > time scale. The conversions from that underlying atomic time scale > should be widely distributed by a robust scheme like the Domain Name > System and financial transactions, and those conversions should not > happen in critical places like the kernel but in other less-critical > places like libraries for locale and internationalization. I fully agree. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On 17 Jan 2019 at 15:57, Brooks Harris wrote: > In private discussion with one member of that committee on that topic > it was said "... but the time people would just not stop arguing!". > Funny how everybody knows what time is but can't agree on what time > is. The music group Chicago discussed this situation decades ago... https://www.youtube.com/watch?v=7uy0ldI_1HA -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/ ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On 2019-01-17 12:38 PM, Steve Allen wrote: On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: Hm, maybe that was originally the case. I wonder whether the folks who wrote the text just had UTC in mind when they "invented" time_t. The best insight into the POSIX committee was posted on LEAPSECS in 2003 https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html In private discussion with one member of that committee on that topic it was said "... but the time people would just not stop arguing!". Funny how everybody knows what time is but can't agree on what time is. -Brooks ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On Thu 2019-01-17T18:12:25+0100 Martin Burnicki hath writ: > Hm, maybe that was originally the case. I wonder whether the folks who > wrote the text just had UTC in mind when they "invented" time_t. The best insight into the POSIX committee was posted on LEAPSECS in 2003 https://www.mail-archive.com/leapsecs@rom.usno.navy.mil/msg00109.html Not clear in that posting was that Arthur David Olson's timezone code for Unix systems already contained the code written by Bradley White which allows time_t to count every second in the radio broadcast time scale and handle leap seconds. POSIX committee members knew that and decided to disregard it with words that actually prevented system designers from adopting a more correct scheme. > So IMO this clearly says that time_t has to be interpreted depending on > the context, and must not necessarily hold exclusively UTC numbers of > second. The tricky part comes when software on one system exchanges values of time_t with another system that believes time_t has a different value. > I think a good solution would be to have a structure that contains a > time_t value plus at least one flag that indicates the leap second > status, or a field with TAI index. It would be even better to have such > additional information available with struct timespec, so an application > can tell if the time stamp is inside a leap second, or not. I think that the entire infrastructure should recognize the notion of needing two kinds of time: precision seconds and civil days. That is what the astronomy community had understood and promoted since before 1950. That is the hard part. It is the part that technical folks punted on doing during the 1960s because it would have required explaining the need for two kinds of time to bureaucrats and legislators and waiting for them to change laws and regulations. Instead they chose to act quickly and implement something controversial and technically barren. The rest of the technical parts needed for the notion of two kinds of time have been discussed here before. The underlying time scale used for radio broadcasts and operations by any kind of machine should be purely atomic. The counting of calendar days and setting of civil clocks should be calculated using an offset from the underlying atomic time scale. The conversions from that underlying atomic time scale should be widely distributed by a robust scheme like the Domain Name System and financial transactions, and those conversions should not happen in critical places like the kernel but in other less-critical places like libraries for locale and internationalization. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
Steve Summit wrote: > Martin Burnicki wrote: >> Just a few general thoughts based on an internal note... > > And some very good points they were. > >> ...The same applies to the time_t type, IMO. If you let the system kernel >> run on TAI or whatever then the time() function still returns a time_t >> data type, but its value represents TAI or whatever has been configured. > > Right... but you may or may not be skating on thin ice! > > I think the question of "Must time_t represent UTC?" can be > a pretty illuminating one, and it cuts across several of the > fundamental issues here. Strictly speaking, the Posix definition > of time_t is, as Warner Losh has argued, very specifically UTC. > (And of course it's also a very specifically non-UTC form of UTC.) Hm, maybe that was originally the case. I wonder whether the folks who wrote the text just had UTC in mind when they "invented" time_t. As I've mentioned earlier, also "struct time_spec" has a time_t field, and the page http://pubs.opengroup.org/onlinepubs/7908799/xsh/clock_settime.html says: "All implementations support a clock_id of CLOCK_REALTIME defined in . This clock represents the realtime clock for the system. For this clock, the values returned by clock_gettime() and specified by clock_settime() represent the amount of time (in seconds and nanoseconds) since the Epoch. An implementation may also support additional clocks. The interpretation of time values for these clocks is unspecified." So IMO this clearly says that time_t has to be interpreted depending on the context, and must not necessarily hold exclusively UTC numbers of second. > But it's equally true, as Gary Miller and Martin have argued, > that in practice people use time_t for all sorts of other things... > but I think we can also agree that (some of the time, at least) > this can lead to additional real confusion, precisely because it > breaks the spec, precisely because doing so may clash with someone > else's spec-based assumptions. I don't think this breaks the spec, see above. IMO, time_t is just the type of parameters used with time(), gmtime() and friends, its bit width is implementation defined, but if you use it you are always safe to use an appropriate data type with those functions. > But the real tragedy is that UTC is the timescale that time_t is > the *worst* at representing, precisely because time_t is a uniform > count of seconds since an epoch, and UTC is nonuniform. Anyone > who tries to "fix" some time_t-using software to do UTC "properly" > is doomed to failure. At best they'll end up reinventing TAI. > > To my mind, a pretty good litmus test for how good an alleged > scheme for properly handling leap seconds actually is is to look > at its data structure. Can it represent :60 explicitly and > unambiguously? If not, it's probably a kludge that's never going > to work perfectly. (But, indeed, the near universality of time_t > and related representations is one of the factors that makes > "solving" the leap second problem almost impossible, and will > likely help lead to the abandonment of leap seconds.) I think a good solution would be to have a structure that contains a time_t value plus at least one flag that indicates the leap second status, or a field with TAI index. It would be even better to have such additional information available with struct timespec, so an application can tell if the time stamp is inside a leap second, or not. > This message will get too long if I start discussing the data > structures that *can* represent :60 explicitly and unambiguously. > Some of them are: > * struct timespec (using the nonnormalized trick described under > "Additional clocks" at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html) > * struct tm > * the pair (days-since-epoch, seconds-within-day) > * a time_t *plus* a well-defined bit disambiguating the two > instances of a repeated second across a leap second If a timestamp has an associated status information available then it is no problem for a library function like gmtime() or localtime() to set the seconds field to 60 during a leap second. We use a similar approach in the library functions we use for the firmware of our PCI cards, etc. On the other hand, if you normalize "60" seconds you get one more minute which lets 59 increase to 60, and so on, so you will also get the effective date/time twice. It's just a question how to interpret the numbers. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy ___ LEAPSECS mailing
Re: [LEAPSECS] Running on TAI
Martin Burnicki wrote: > Just a few general thoughts based on an internal note... And some very good points they were. > ...The same applies to the time_t type, IMO. If you let the system kernel > run on TAI or whatever then the time() function still returns a time_t > data type, but its value represents TAI or whatever has been configured. Right... but you may or may not be skating on thin ice! I think the question of "Must time_t represent UTC?" can be a pretty illuminating one, and it cuts across several of the fundamental issues here. Strictly speaking, the Posix definition of time_t is, as Warner Losh has argued, very specifically UTC. (And of course it's also a very specifically non-UTC form of UTC.) But it's equally true, as Gary Miller and Martin have argued, that in practice people use time_t for all sorts of other things... but I think we can also agree that (some of the time, at least) this can lead to additional real confusion, precisely because it breaks the spec, precisely because doing so may clash with someone else's spec-based assumptions. But the real tragedy is that UTC is the timescale that time_t is the *worst* at representing, precisely because time_t is a uniform count of seconds since an epoch, and UTC is nonuniform. Anyone who tries to "fix" some time_t-using software to do UTC "properly" is doomed to failure. At best they'll end up reinventing TAI. To my mind, a pretty good litmus test for how good an alleged scheme for properly handling leap seconds actually is is to look at its data structure. Can it represent :60 explicitly and unambiguously? If not, it's probably a kludge that's never going to work perfectly. (But, indeed, the near universality of time_t and related representations is one of the factors that makes "solving" the leap second problem almost impossible, and will likely help lead to the abandonment of leap seconds.) This message will get too long if I start discussing the data structures that *can* represent :60 explicitly and unambiguously. Some of them are: * struct timespec (using the nonnormalized trick described under "Additional clocks" at https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html) * struct tm * the pair (days-since-epoch, seconds-within-day) * a time_t *plus* a well-defined bit disambiguating the two instances of a repeated second across a leap second ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
Hi all, Rob Seaman wrote: > Our Meinberg ref clocks can deliver GPS, UTC, or TAI (and thus other > derived timescales). Yes, and the same data formats are used for each of these time scales. Just a few general thoughts based on an internal note, instead of replies to individual posts here on the list: IMO you have to generally distinguish between specific data formats, and the type of information a particular data type can contains. For example, the 32:32 bit timestamp type used in NTP packets has been specified to provide UTC. But of course, if you configure your timeserver for a different time scale than UTC then it just transports "a time" according to the configured scale. I'm sure that even the UT1 NTP server operated by NIST puts a UTC timestamp into those fields. The same applies to the time_t type, IMO. If you let the system kernel run on TAI or whatever then the time() function still returns a time_t data type, but its value represents TAI or whatever has been configured. Even if you have separate API calls that either return TAI, UTC, or whatever from the kernel you can use the same data format for the returned timestamps. In fact, clock_gettime() always returns the same data type (struct timespec, which includes a time_t field), but the type of information differs depending depending on the specified clock ID, and may be a UTC time, a number of seconds and nanoseconds since boot, or whatever. IMO the basic problem is in many cases that some extended information is missing. For example, if you receive an NTP packet you are basically unable to distinguish if the time in the packet is really UTC, or something else. However, if you know that the packet originates from a UT1 server you can assume that it transports UT1 rather than UTC. Similar with time_t. If you read timestamps in a fast loop across an inserted leap second you can only distinguish times if you have a leap second status flag associated with the time, so when kernels simply step the time back to insert a leap second you don't know if the "UTC midnight" timestamp is represents the original second, or the repeated second, which is in fact the leap second. This is similar to the end of DST, where a pure hh:mm:ss time doesn't tell if it belongs to the first hour, or to the repeated hour. You know this only if you can retrieve the DST status with the time in a consistent way, so the first time has DST enabled and the repeated time has it disabled. Even if a DST flag is available (e.g. in struct tm), you don't know from the information from the structure alone if the time the structure contains is UTC, or local a time according to whichever time zone has been configured. Generally it makes a difference whether you simply need the current time which steps when a leap second is applied to UTC, or when DST changes for local time, and continues ticking normally after that event, or if you have to deal with time *intervals*. If your application deals with time *intervals* then it has to be aware that the day is one second longer than usual if a leap second has been inserted, and in local time even one hour longer at the day when DST ends. I think developers more often care about DST steps than leap second steps because DST steps simply occur more often, in shorter intervals. If you need to convert GPS time or TAI to UTC, or vice versa, then of course you need some source of information that tells the current UTC/TAI or UTC/GPS offset. This is also the case if your kernel runs on TAI. There are different possible sources which provide different amount of information. For "current" times the information that can be provided by the NTP or PTP protocol, or from a GPS receiver, is sufficient. However, if you need to deal with historic time intervals then a leap second table is required which explicitly tells at which points in time leap seconds have been inserted. This is just similar to dealing with historic local times, where the TZ DB provides information if and when a DST changeover occurred in the past. Neither GPS, nor PTP or NTP provide this historic information, but e.g. the TZ DB also includes a leap second table, or you can get the leap second file directly from the sources (IERS, NIST, USNO, ...). The problem here is that a leap second table as well as the TZ DB has to be kept up-to-date by some means, since upcoming changes can't be predicted automatically. This requirement is not only for TAI/GPS to UTC conversion. Also if you need to derive e.g. UT1 from TAI, GPS or UTC you have to provide some information (e.g. a data file) how the UT1 offset develops over time, and this information has to be updated in regular intervals. Sorry for the long post which just tries to summerize a couple of things. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burni...@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9,
Re: [LEAPSECS] Running on TAI
Hi Hal, Again, it doesn't appear that the current discussion has anything to do with astronomical use cases. >> The trick is to find a source that will set a POSIX system to TAI, and then >> to avoid the gotchas that happen when such a system interacts with other >> POSIX systems. > What do the systems that point telescopes use for maintaining their system > clock? Do they use NTP or a special program that listens to GPS or a local > Hydrogen maser or ...? Radio telescopes (or LIGO, for instance) may have extremely high precision requirements (and thus fancy clocks), at least as much for frequency as time. Most other telescopes need accurate time more than high precision time. Telescopes tend to be in remote locations (mountains, Antarctica, in orbit, etc) and generally rely on GNSS clocks. These vary in quality according to the observatory budget. NTP is used across whatever mountaintop network is deployed, but may be poorly behaved across microwave links to remote campus pools, for instance. > Some GPSDOs have the option to return GPS time rather than UTC. Our Meinberg ref clocks can deliver GPS, UTC, or TAI (and thus other derived timescales). > GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All > it takes is a little sysadmin hacking, no programming. Yes, but there may be significant operational details, e.g., we have red clocks for UTC in our control rooms and white clocks for local time, but might want green for TAI or so forth. There are a lot of potential timekeeping requirements depending on the science and logistics. > You won't easily get redundancy from checking with other NTP servers. If you > have several friends running similar systems, you could set up a private NTP > network. We operate four telescopes currently on two mountaintops. Three GNSS clocks (one campus spare) plus a couple of IRIG-driven linux kernel implemented stratum-0 ref clocks per telescope provide plenty of NTP stratum-1 references. Don't know about a private NTP network, the campus stratum-2 pool clocks generally don't get given the time of day, so to speak, but we want something remote for fail-over. (Would have to be a pretty intrusive local network event to get there.) > With some work it would be reasonable to setup a ntp server that took in UTC > but gave out TAI. That would be similar to the way leap smearing works. We > could use a separate port number to minimize confuzion. Also, NIST has a UT1 reference, but I for one haven't had luck connecting. > As far as I know, the kernel doesn't know anything about what type of time it > is maintaining. It just sets the clock as directed and goes tick, tick, > tick. > The trouble is with the time conversion routines. They all assume a time_t > is UTC. So if you ran your system on TAI, all your log files would be off by > 37 seconds. "Off" from what? If the system is set to GPS, TAI, UT1 or whatever, the log files arguably should be as well. > How hard would it be to insert a wrapper in front of the time conversion > routines? The idea is to rename all the current time conversion routines > from > foo to foo_utc and implement foo_tai that concerts between UTC and TAI. It > would need a list of leap seconds. The default implementation of foo would > call foo_utc but an environment variable or such would switch to using > foo_tai. Or use Steve's TZ-based solution. Rob ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Running on TAI
On 1/15/19 4:19 PM, Hal Murray wrote: The trick is to find a source that will set a POSIX system to TAI, and then to avoid the gotchas that happen when such a system interacts with other POSIX systems. What do the systems that point telescopes use for maintaining their system clock? Do they use NTP or a special program that listens to GPS or a local Hydrogen maser or ...? Some GPSDOs have the option to return GPS time rather than UTC. GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All it takes is a little sysadmin hacking, no programming. You won't easily get redundancy from checking with other NTP servers. If you have several friends running similar systems, you could set up a private NTP network. With some work it would be reasonable to setup a ntp server that took in UTC but gave out TAI. That would be similar to the way leap smearing works. We could use a separate port number to minimize confuzion. As far as I know, the kernel doesn't know anything about what type of time it is maintaining. It just sets the clock as directed and goes tick, tick, tick. The trouble is with the time conversion routines. They all assume a time_t is UTC. So if you ran your system on TAI, all your log files would be off by 37 seconds. How hard would it be to insert a wrapper in front of the time conversion routines? The idea is to rename all the current time conversion routines from foo to foo_utc and implement foo_tai that concerts between UTC and TAI. It would need a list of leap seconds. The default implementation of foo would call foo_utc but an environment variable or such would switch to using foo_tai. Some modules (Python skyfield package from Rhodes Mill) explicitly deal with this. The time object has a method for each time scale.. These return utc in various formats time.utc_jpl() time.utc_iso() time.utc_datetime() These return other timescales time.tai time.tt time.J time.ut1 I confess I have used them blindly without checking, but I can do that quickly. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] Running on TAI
> The trick is to find a source that will set a POSIX system to TAI, and then > to avoid the gotchas that happen when such a system interacts with other > POSIX systems. What do the systems that point telescopes use for maintaining their system clock? Do they use NTP or a special program that listens to GPS or a local Hydrogen maser or ...? Some GPSDOs have the option to return GPS time rather than UTC. GPS is a fixed offset from TAI. So it's easy to run your system on TAI. All it takes is a little sysadmin hacking, no programming. You won't easily get redundancy from checking with other NTP servers. If you have several friends running similar systems, you could set up a private NTP network. With some work it would be reasonable to setup a ntp server that took in UTC but gave out TAI. That would be similar to the way leap smearing works. We could use a separate port number to minimize confuzion. As far as I know, the kernel doesn't know anything about what type of time it is maintaining. It just sets the clock as directed and goes tick, tick, tick. The trouble is with the time conversion routines. They all assume a time_t is UTC. So if you ran your system on TAI, all your log files would be off by 37 seconds. How hard would it be to insert a wrapper in front of the time conversion routines? The idea is to rename all the current time conversion routines from foo to foo_utc and implement foo_tai that concerts between UTC and TAI. It would need a list of leap seconds. The default implementation of foo would call foo_utc but an environment variable or such would switch to using foo_tai. -- These are my opinions. I hate spam. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
