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] leapseconds, converting between GPS time (week, second) and UTC
On Wed 2019-01-16T22:24:46-0800 Paul Hirose hath writ: > On 2019-01-16 1:35, Steve Allen wrote: > > > > Does it know that rubber seconds do not apply to timestamps in central > > Europe made using DCF77 from 1970-01-01 to 1972-01-01? > > All my DLL knows is what's in the UTC file. If the file indicates no rate > offset in the years 1970-71 and some fractional second step adjustments, > that's what you get. An existing file could be edited to match the DCF77 > flavor of UTC. Then construct a UtcTable object from the file: There lies the problem with timestamps, then and now. The folks running DCF77 had convinced themselves that German law did not permit them to broadcast seconds which were not SI seconds, so they stopped broadcasting the rubber second version of UTC which was then the CCIR standard. Instead they convinced themselves that broadcasting "mostly legal" SI seconds was more acceptable under German law. The issues of Bulletin Horaire over the decades show that the existence of any difference between the time signal broadcasts of any service was not acceptable and repeatedly resulted in internatioal meetings with recommendations putting pressure on every transmitter to conform. This was the reason for the creation of UT2. In the 1950s the issues of Bulletin Horaire show that the UK had started correcting their broadcasts, first for what would become called UT1, and then for what would be called UT2. The US Navy broadcasts did likewise, but using a different expression for what would become called UT2. The US NBS WWV broadcasts chose to prefer more steps and fewer frequency offsets than US Navy because the NBS was more interested in standard frequency than in astronomical time. Bulletin Horaire says that by 1955 there were at least 4 different schemes being used to produce broadcasts of time scales akin to what would become called UT2. Bulletin Horaire explains that was the motivation behind the 1955 IAU decision to create UT0, UT1, and UT2. Then folks became uncomfortable with the way that different stations attacked the problem of broadcasting something like UT2. The US Navy method of approximating UT2 using fewer time steps and more changes of frequency offset was good for navigators who would not see their position suddenly shift. The US Navy method was also an irritant, in part to folks who had been driving CCIR recommendations toward making better use of spectrum by reducing spacing between stations using adjacent frequencies, and in part to engineers who had to retune the transmitting gear. The existence of cesium frequency standards made it easy for everyone to see the changes in offsets that had previously been hard to measure, but it also allowed for the agreement on the original form of rubber second UTC where everyone agreed to use the same frequency offsets and time steps. The first version of that agreement was forged over tea in the living room of H.M. Smith, one of the Greenwich engineers associated with UK radio broadcast time signals over the span of his career. After the US and UK had codified their rubber second agreement it was taken to URSI, CCIR, and IAU to get official international status as recommendations. After the CGPM approved the cesium SI second, the German decision that in 1970 they would no longer conform to rubber second UTC led to urgent need to create yet another agreement on a different way of broadcasting time that could be legally tolerated in all countries. There was also dissatisfaction with the changes in frequency and time steps from the LORAN engineers who had to re-tune and re-phase entire chains of transmitters, and the LORAN users who could not navigate during the interval when the chain was retuning and rephasing. So for your software the German decision means that the only way to decode timestamps in central Europe from 1970/1972 is to find the publications where they announced when DCF77 inserted their markers which were spaced by 1.2 SI seconds. The USNO circulars which announced changes in their broadcasts were printed on high-acid paper which has self-destructed while sitting in the few libraries which bothered to store them. I do not even know the name of the German publications which would have announced their time signal steps. -- 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
