Re: [LEAPSECS] prep for WRC 23
On 2023-12-22 22:35, Seaman, Robert Lewis - (rseaman) wrote: E pur si muove Natura non facit saltus -- why should UTC? UTC may no longer serve as a kind of solar time (after 2026 or 2035, or somebody said 2040 the other day), but civil time will continue to have engineering requirements tracing to both solar and atomic time scales. As far as required by local civil time scales, continuous UTC can stand for solar time (UT1 up to 15 min) for several centuries. Current positioning applications on the surface of the Earth cannot be performed without knowledge of UT1 up several milliseconds. These applications work in wrist watches today and they do not need nor exploit the leap seconds of UTC. What type of engineering requirements can be satisfied with the current UTC with leap seconds that fail when UTC becomes continuous? The Russians have required more time for updates in satellite software, they have not said that it cannot be done. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
On 2023-12-21 18:22, Poul-Henning Kamp wrote: My Tl;dr version of the resolution is: . Please keep DUT1 less than 100 seconds. I do not read that from the text. The original [page 399] says: " recognizing . k) that the maximum value for the difference between UT1 and UTC should be no less than 100 seconds, taking into account the constraints of the technological systems expected to be used to disseminate this value, " This seems to say that on the contrary, at least 3 decimal digits will be needed for the integral part of the approximation of |UT1 - UTC| in time signals that include an estimate of UT1 - UTC after 2035. Anyway, I do not think that the CIPM will recommend a maximal value of 100 s for |UT1 - UTC| because there is a slim chance that this will not be enough until 2135. On the other hand, ITU-R might come up with a scheme where the approximation of (UT1 - UTC) is only given modulo 100 s in radio signals, so that 2 digits would suffice for the integral part. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
On 2023-11-26 06:59, Steve Allen wrote: This week began the meeting of ITU-R WRC 23. ..and it ended on 2023-12-15. The ITU-R news channel [https://www.itu.int/en/mediacentre/Pages/PR-2023-12-15-WRC23-closing-ceremony.aspx] mentions a "key outcome"of WRC23: " ∙ Endorsement of the decision by the International Bureau of Weights and Measures (BIPM) to adopt Coordinated Universal Time (UTC) as the de facto time standard by 2035, with the possibility to extend the deadline to 2040 in cases where existing equipment cannot be replaced earlier. " It is unclear what this is intended to mean: endorsement of the CGPM (not BIPM) decision implies that UTC will be continuous (not "de facto standard") from 2035 onward, so what "deadline" may still be shifted to 2040? ITU-R continue their (and CCIR's) tradition of murky statements about UTC. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
On 2023-11-26 06:59, Steve Allen wrote: This week began the meeting of ITU-R WRC 23. After closure of work related to resolution 655 of WRC 2015 at the World Radio Conference 2023 in Dubai, the BIPM has added the web page [https://www.bipm.org/en/-/2023-12-12-wrc-dubai] One particular technical aspect is mentioned on this page: some lead time is required to adapt the (few) radio time signals that disseminate the approximation DUT1 of UT1 - UTC to the larger range of |UT1 - UTC| that will be allowed after 2035. This is worded quite implicitly, so that one cannot be sure ∙ whether there will still be an official approximation of of UT1 - UTC after 2035, similar to the one currently produced by the IERS with Bulletin D; ∙ if, yes, what the resolution and the range of that approximation would be. The CIPM will certainly try to avoid to introduce an official approximation of UT1 - UTC with a resolution of whole seconds and whose values change only at the end of a UTC month. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
On 2023-11-26 17:38, Michael Deckers wrote: online at [https://www.itu.int/oth/R0A0807/en] when he meant: nline at [https://www.itu.int/pub/publications.aspx?lang=en&parent=R-REP-TF.2511-2022] Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] prep for WRC 23
On 2023-11-26 06:59, Steve Allen wrote: This week began the meeting of ITU-R WRC 23. One preparation for this meeting was a document issued early this year The future of Coordinated Universal Time https://www.itu.int/en/itunews/Documents/2023/2023-02/2023_ITUNews02-en.pdf This looks at the use of time in several arenas, many of which would like UTC to stop having leap seconds. The result of resolution 655 of WRC 2015 is ITU-R document TF 2511-0, online at [https://www.itu.int/oth/R0A0807/en]. It gives an overview of how users of UTC are affected by the current (discontinuous) form of UTC and by the proposed continuous form; it was written before the CGPM decision of 2022 on the change in UTC. Many also allow that keeping agreement with the earth in the long run is necessary, and that they have no idea how to do that. A working group of the CCTF has since been charged with developing (among other, more important things) a proposal for measures to constrain |UT1 - UTC| after the new bound is reached. Since such measures would only apply in over 100 years, when the requirements for a reference time scale cannot reliably be predicted, anything beyond a necessarily incomplete list of possibilities (a discontinuous step, change in the rate d(UTC)/d(TT), using predictions of UT1 - UTC, etc) would be wasted effort. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] negative leap second milestone
On 2023-08-26 17:58, John Sauter via LEAPSECS wrote: According to the IERS, today, for the first time since the establishment of the modern definition of UTC in 1973, the quantity UT1-UTC crosses zero while increasing. If this continues we will have a negative leap second, probably some time in the 2030s. https://datacenter.iers.org/data/html/bulletina-xxxvi-034.html I do not think that a negative leap second is coming up so soon with the latest predictions of the IERS. At the currently predicted LOD of -0.08 ms/d, it takes 24 years for UT1 - UTC to increase from 0.0 s to 0.7 s; and by then, leap seconds will have been "suspended". Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] speeding up again?
On 2023-06-20 12:21, Michael Deckers via LEAPSECS referenced: [https://link.springer.com/chapter/10.1007/1345_2022_167] which was already cited by Richard Langley on 2023-06-17. Sorry for the duplication. MD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] speeding up again?
On 2023-06-16 01:48, Tom Van Baak wrote about the relationship of LOD with El Niño: Attached is an LOD plot I made a while ago. A random web google link says "The five strongest El Niño events since 1950 were in the winters of 1957-58, 1965-66, 1972-73, 1982-83 and 1997-98". To my eyeball I just don't see that in the historical LOD plot. The relationship between LOD and the El Niño events is not so easy to spot, see eg [https://link.springer.com/chapter/10.1007/1345_2022_167] Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] speeding up again?
On 2023-06-16 13:46, jimlux wrote: 10 terasquare meters You mean 10 square megameters = 10 Mm²; SI suffixes apply to named units, not to its powers. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Inside GNSS published an update of my CGSIC talk
On 2023-03-20 19:36, Michael Deckers wrote: This seems to be lenient enough to allow for not scheduling a negative leap second even in the case that the difference (UT1 - UTC) should go a bit below -1 s before 2035. when he meant "a bit above +1 s" MD. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Inside GNSS published an update of my CGSIC talk
On 2023-03-20 07:54, Jürgen Appel via LEAPSECS wrote: In your Conclusion, you say "the CGPM resolution also stipulates that no change to current practices can occur before 2035." This is not how I read read the CGPM document on the BIPM website: "The General Conference on Weights and Measures (CGPM), at its 27th meeting [...] decides that the maximum value for the difference (UT1-UTC) will be increased in, or before, 2035," So in case the negative leap seconds become a real threat, according to my interpretation is is an option to increase the tolerance value earlier than 2035 to avoid trying out negative leap seconds a last and first time. Can someone confirm my view? You read correctly, the French (official) version has ..."décide que la valeur maximale pour la différence (UT1 - UTC) sera augmentée au plus tard en 2035," which means "in 2035 at the latest". Note also that the definition of UTC as approved by the CGPM never mentions _any_ explict bound for |UT1 - UTC|; it only says that (TAI - UTC) is an integral multiple of 1 s as determined by the IERS. It is the IERS who state that "Coordinated Universal Time (UTC) a measure of time that conforms, within approximately 1 s, to the mean diurnal motion of the Sun and serves as the basis of all civil timekeeping." quoting the IAU "Nomenclature for Fundamental Astronomy (NFA)" found at http://syrte.obspm.fr/iauWGnfa/NFA Glossary.html. This seems to be lenient enough to allow for not scheduling a negative leap second even in the case that the difference (UT1 - UTC) should go a bit below -1 s before 2035. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] King Charles
On 2022-12-04 17:01, Steve Allen wrote: On Sun 2022-12-04T16:30:01+ Tony Finch hath writ: So if you agree with Donald Sadler, has already GMT concluded. I do agree, and I also disagree, for Sadler was in large part responsible for another tacit change to GMT. Like others engaged in the present redefinitions, given his job Sadler could not have dared to describe the consequences of that in plain language. The upcoming redefinition of UTC may well be seen as the logical consequence of its tremendous success as a reference time scale: billions of devices need an easily accessible continuous time scale with constant rate for sequencing events and for the computation of time derivatives. And the secular deviation of UT from UTC in the future might be one of the consequences that you think D H Sadler did not dare to describe in plain language. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] future access to solar time?
On 2022-11-21 14:19, Seaman, Robert Lewis - (rseaman) wrote:
In a post-leap-second world, precision values for dUT1 either become more
critical or less. Or rather, they become no-less important scientifically but
perhaps negligible politically. For
example,https://www.sciencedirect.com/science/article/pii/S0273117719302388
says “Global Navigation Satellite Systems (GNSS) are dependent on VLBI as they
need dUT1 to maintain its operability”.
I am not sure if we mean the same thing by "dUT1". I used
it in the sense:
dUT1 is an additonal correction to UTC so that
UTC + DUT1 + dUT1
is a better approximation of UT1 than just
UTC + DUT1
and takes its values in the set {0, ±20, ±40, ±60, ±80} ms.
dUT1 in this sense is used only by some Russian time signals,
and its value is not defined by the IERS. Moreover, since the
amplitude of UT1 - UT2 is about 34 ms, dUT1 must be adjusted
for annual variations of UT1 - UTC.
I have seen the term "dUT1" to be used for ΔUT1 = UT1 - UTC
(and that is how I read it in the paper you quoted), and
also for the rate d(UT1) -- but these are different beasts.
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] future access to solar time?
On 2022-11-20 15:15, Tony Finch asked: (Do any of the national broadcast signals actually follow the ITU spec?) Lists of UTC time signals with details about the coding are in the Annual reports of the BIPM time department, at [https://www.bipm.org/en/time-ftp/annual-reports]. A few of them transmit DUT1 (and even dUT1). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Alanna Mitchell in NYT
On 2022-11-14 19:48, Steve Allen wrote: The NYT article ends with Arias ruminating about how someday there will have to be a leap minute or leap hour. Of course, nobody will propose leap minutes or leap hours in UTC after 2135 just to decrease the difference UTC - UT1. The reason why the CIPM (for now) sticks to the requirement that |UTC - UT1| be bounded is most probably the argument brought forward by some people from ISO who say that, without explicit bound on |UTC - UT1|, UTC had to change its name so that "polysemy" is avoided. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] fb/meta join the leap second haters
On 2022-07-26 05:08, Steve Allen wrote: The CNET article includes a quote from correspondence which repeats a trick that has been performed since the 1960s, that being to produce a significant underestimate of the difference between solar and atomic time by saying that the absence of leap seconds will not be noticed for 2000 years. The CGPM resolution to be adopted in November, online at [https://www.bipm.org/documents/20126/66742098/Draft-Resolutions-2022.pdf/2e8e53df-7a14-3fc8-8a04-42dd47df1a04] only requires continuity of UTC - TAI for 100 years. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] IERS Bulletin D141
Another first has happened: Bulletin D141 at [https://datacenter.iers.org/data/latestVersion/17_BULLETIN_D17.txt] specifies that DUT1 jumps from -0.2 s to -0.1 s on 2021-07-21T00Z. This is the first time ever (since 1972) that the approximation UTC + DUT1 of UT1 makes a jump upwards (is advanced). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] DUT1 about to backtrack
On 2021-01-08 19:57, John Sauter via LEAPSECS wrote: I attach a plot of historical values of DUT1 based on the old issues of Bulletin A kept on the IERS' web site. I think the graph of DUT1 is not quite correct, for instance: On 2009-01-01, there was a switch of DUT1 from -0.6 s to +0.4 s due to a leap second (Bulletin C36) On 2009-03-12, there was a switch of DUT1 from +0.4 s to +0.3 s (Bulletin D102) Your graph only has one switch, on 2009-01-01 from -0.6 s to +0.3 s Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
[LEAPSECS] LOD reaches 0 s/d
The latest Bulletin A [https://datacenter.iers.org/data/latestVersion/6_BULLETIN_A_V2013_016.txt] predicts that d(UT2)/d(TAI) = 1 after 2021-11-13, ie the rates of UTT2 and TAI are expected to agree for the next year. This has never happened since 1961. We may not need to abolish leap seconds for quite a while. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] long interval predicted
On 2020-08-08 10:46, John Sauter via LEAPSECS wrote: UT2 captures the seasonal change in the length of day, so it can be ignored for long-term estimates. The important number, therefore, is -0.00010, which I will call the UT1 slope. Perhaps "slope of UT2 - UTC (as predicted by the IERS)" would be a better name, as the formula of Bulletin A implies (by taking the derivative after adding the implied units): d(UT2)/d(UTC) = 1 - 0.10 ms/d. But anyway, UT2 still contains known short period (<= 35 d) fluctuations, and currently, the combined amplitude of these fluctuations exceeds by far the indicated secular trend of UT2 during their periods. Another observation, namely the increase in the uncertainty of UT1 - TAI as given in the long term EOP parameters (published by the IERS in [https://datacenter.iers.org/data/latestVersion/38_EOP_C01.1900-NOW_V2013_0138.txt]) from 4 µs to 30 µs since J2020.40 = 2020-05-26.6 may be a related effect. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C number 60
On 2020-07-07 22:37, Steve Allen wrote: The earth has accelerated so that it is spinning as fast as it was during World War 2, and before that, the 1890s. Yes, Bulletin A vol 33 no 027 predicts that 2020 will be the first year since 1972 without change of DUT1 (= UT1 - UTC up to 0.1 s). And its prediction for the (seasonally smoothed) length of day after 2021.5 is d(UTC)/d(UT2) ~= 1 + 0.13 ms/d. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
On 2020-02-04 21:16, Steve Allen wrote:
The first time that the 4th meeting of the CCDS happened was in 1966,
but that meeting is not found in any official record. The meeting
ended with a vote to recommend that the CGPM should adopt an SI second
based on cesium, but the circumstances of that vote were deemed so
abusive that the entire meeting was nullified. That did not stop the
rush for an atomic second. During the next year subsets of the CCDS
members gathered for discussions at other meetings. When the second
4th meeting of the CCDS was held in 1967 they did recommend the cesium
second to the CGPM.
From the standpoint of a physicist, the 1960 definition of the SI second
(based on ET and Newcomb's tables for the Sun) was extremely
impractical.
With the wide availability of Cs clocks, the atomic second was much
easier and more precisely reproducible than the SI second, so a
redefinition of the second (or at least a practical unit, as with
the recently abolished practical volt and ohm) was urgent.
On the other hand, you are certainly right that the actions of the
CCDS in 1967 appear strange: they propose to redefine the SI second,
and then go on to propose that the BIH, IAU, IUGG, URSI, and CCIR
study the problems arising from the new definition ("étudier les
problèmes soulevés par l'application des décisions prises
concernants la nouvelle définition de l'unité du temps").
Apparently, it did not even occur to them that this is bad
engineering.
The proposal of the IAU GA13 in 1967 to introduce an (unsteered)
international atomic time scale would have allowed to study the
possible problems of a redefinition of the SI second before
applying it.
Folks at the PTB took a different aim by introducing draft legislation
that the German government passed in 1969. The law made it illegal
for the German government to broadcast anything other than SI seconds,
and it would become effective in 1970. This seems to have pulled the
trigger on the CCIR process, for without some kind of quick action a
major nation would be broadcasting time signals using a different
scale than other nations.
The law on legal units in West Germany, from 1969-07-02, lists under
the title "tasks of the Physikalisch-Technische Bundesanstalt"
that the PTB has to publicize the procedures by which units without
material prototype are realized, including the units of time and
time scales, as well as the temperature unit and temperature scales.
(" hat die Verfahren bekanntzumachen, nach denen nicht verkörperte
Einheiten, einschließlich der Zeiteinheiten und der Zeitskalen
sowie der Temperatureinheit und Temperaturskalen, dargestellt
werden,")
This can be taken to imply the task to disseminate a standard
frequency (which they already did). But in my opinion it does not
imply that UTC must have the same rate as the atomic time scales
at the time -- the law even allows for several time scales.
I'll try to find out how the PTB was involved in this legislation
as far as time in concerned. In Germany, federal law can only
be proposed by members of parliament, and by federal and state
governments; but the PTB was certainly heard during the legislative
process.
In my home state of California the process that led to UTC with leap
seconds would have been illegal under the Brown Act that requires
public access to meetings. But in the full context that is not the
most criminal aspect of the process that led to the 1970 CCIR
decision.
Yes, and the ITU-R deliberations before the WRC in 2015 were not
transparent either. Nevertheless, past decisions of the CCIR and
the IAU have become accessible nowadays.
Let's hope that the CIPM treats any future discussions about
a redefinition of UTC in an open manner, and that it adheres
to rational design and decision processes. The recent revision
of the SI has been largely transparent and guided by good practices.
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
On 2020-02-04 13:44, Tony Finch wrote: The IERS Bulletins C state a value of UTC-TAI "until further notice". However the machine-readable files from IERS and NIST give an expiry date of a few days less than 6 months after the announced (lack of) leap second, or a bit more than 11 months after the latest Bulletin C. Is this expiry date reliable or just advisory? History suggests it's reliable, but the standards do not. It's unclear to me what governs the frequency of announcements or their validity period, i.e. where are current practices documented? what is the process for changing them? how will we know if a change is planned? and so on. This is all about how much we can assume that the IERS will continue to operate leap seconds as they have for nearly 50 years, or whether they will make use of the much weaker guarantees given by TF.460, or (wishful thinking) whether they can schedule leap seconds further in the future. The IERS (and BIH) policy to use only the primary choices for the insertions of leap seconds is only guaranteed in the text of Bulletin C -- if LOD increases sufficiently, that text will have to change. There is a similar situation for Bulletins D -- each of them announces when the next one is expected to be issued. But even nowadays these predictions of UT1 - UTC are not very reliable, and they often err on the "wrong" side (DUT1 changes earlier than predicted). For instance, Bulletins D139, D134, and D129 each came earlier than predicted by the preceding Bulletin D; Bulletin D129 (of 2016-04-15) was even significantly earlier (45 d) than predicted by Bulletin D128 (of 2016-02-19). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
On 2020-02-02 22:30, Steve Allen wrote: On Sun 2020-02-02T17:59:20+ Michael Deckers hath writ: The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in 1974 by CCIR Rec. 460-1 has never been violated until now. That violates the agreement that the difference between UTC and UT1 would be encoded as part of the time broadcasts. Actually, the difference |UTC - UT1| has always been < 0.8 s except around 1973-01-01. And DUT1 has assumed the value 0.8 s only once, for a few days on and after 1994-07-01, as specified in Bulletin D46 (online at [https://datacenter.iers.org/data/17/bulletind-046.txt]). That Bulletin is remarkable in several respects: it describes two switches of DUT1, not just one, and it was issued on 1994-06-21, only 10 days before the first switch (rather than a month before it, as was requested -- from the BIH -- in CCIR Rec 460-4 of 1986). In one case it was broken specifically because a high official at CCIR conceded to a high official from USSR and directed the BIH to violate the wording of the existing agreement. Do you mean the only violation of applicable CCIR rules, the introduction of a leap second into UTC at 1973-01-01? Right. Sadler covers this in his memoir and in several contemporary publications. Delving into this reveals more of the fear in the process. Several memoirs show that the principals involved with the creation of UTC with leaps were very concerned that the change of broadcast time signals might cause havoc with ships using celestial navigation. Reading through those shows palpable relief when they managed to evoke from the Maritime Safety Committee of the IMCO a statement that Rec. 460 would not cause difficulties with navigation predicated on the expectation that governments whose radio broadcasts used new UTC would issue notices about the change of their broadcasts. That meant that the Time Lords did not have their arses on the line if a ships might collide as a result of the new system. With the maximum difference of 0.7 s that could be encoded in the radio broadcasts not being able to handle the 0.9 s difference that put their arses back on the line. Other concern was expressed that exceeding the 0.7 limit might be blamed on the BIH and might trigger governmental review of the operation and funding of the BIH. At that time about 80% of the funds for BIH were coming from Observatoire de Paris as slush from their allotment from the French government. That was hardly an "international" arrangement, but BIH had only just been handed the responsibility for maintaining TAI specifically because any other arrangement would have required effectively duplicating the expertise and hardware of the BIH and finding a way to fund that. Prompting governments or journalists to open an investigation into the process of writing an international "technical" specification that was violated in less than two years was not a welcome notion. Very interesting, thanks for these details! Concerning the technical expertise of the CCIR with time scales: one of the early proposals of the CCIR has been a "stepped atomic time" with steps of 1 s and maximal difference of 0.5 s from UT2 (as mentioned in the 1970 report of commission 31 available via your web site on [https://ui.adsabs.harvard.edu/link_gateway/1970IAUTA..14..343Z/ADS_PDF]) -- apparently they had not consulted any astronomer, even though they used to "request" many actions from the BIH in their specifications of time scales. The 1970 report also contains the proposal that the CIPM should be responsible for the definition of UTC, and 49 years later, the CGPM in 2019 seems to have taken on that task with the resolution [https://www.bipm.org/en/CGPM/db/26/2/] which notably has no requirement that |UTC - UT1| be bounded. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds have a larger context than POSIX
On 2020-02-01 23:59, Steve Allen wrote: In every instance where a document specified a maximum deviation that agreement was later violated. The maximum deviation |UTC - UT1| <= 0.9 s as stipulated in 1974 by CCIR Rec. 460-1 has never been violated until now. In one case it was broken specifically because a high official at CCIR conceded to a high official from USSR and directed the BIH to violate fthe wording of the existing agreement. Do you mean the only violation of applicable CCIR rules, the introduction of a leap second into UTC at 1973-01-01? If so -- this was the choice of using either the date 1973-01-01 for the insertion of the leap second, or a later date before 1973-07-01. This is evident because at the time, the mean excess length of day LOD = d(TAI - UT1)/d(UT1) was observed to be >= 3 ms/d, which is more than 0.5 s per 6 months. Hence the choice was to either stick with the bound 0.7 s for |UT1 - UTC| as required by CCIR Report 517 of 1971, or else stick with the primary choices for the possible dates of the insertion of leap seconds. Apparently, the "high official from USSR" must have preferred the latter. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] complete history of UT2
On 2019-06-05 05:28, Steve Allen wrote: I have plowed through enough of Bulletin Horaire to find the complete history of UT2. https://www.ucolick.org/~sla/leapsecs/seasonal.html Missing from the earlier version of the plots on this web page was the story of how exactly the BIH performed the transition between the first version of UT2-UT1 and the second version. Naively the change of the expression requires a jump of 6 ms at the beginning of 1962, but that is not what the BIH dictated. Look at the middle plot and see how the year started along one curve and finished along the other. Thanks! That clarifies that the 5 ms step down in UTC at 1961-01-01 has nothing to do with the change in the formula for UT2 as a function of UT1. Nowadays, the role of UT2 is reduced: it is given in Bulletin A as a linear function of UTC, as a means to extend the prediction of UT1 as given in the Bulletins. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] DCF77 and the inception of leap seconds
On 2019-02-01 17:56, Steve Allen wrote: The PTB-controlled broadcasts were pure SI seconds thus making those broadcasts a form of Stepped Atomic Time which was approved as experimental by CCIR Rec 374-1 in 1966. The DCF77 service started on 1959-01-01 and sent astronomically determined signals for UT2 or UTC until 1970-04-01 when the signals of DHI stopped. The PTB used Cs clocks since 1962, and the PTB time signals in DCF77 used steps but never used an offset in rate. See Andreas Bauch, Peter Hetzel, Dirk Piester: "Zeit- und Frequenzverbreitung mit DCF77: 1959 – 2009 und darüber hinaus". in: PTB Mitteiliungen, 2009 Heft 3. 2009-09 Braunschweig. online at [https://www.ptb.de/cms/fileadmin/internet/publikationen /ptb_mitteilungen/mitt2009/Heft3/PTB-Mitteilungen_2009_Heft_3.pdf] Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the epoch of TAI, with no more doubt
On 2019-01-22 05:17, Steve Allen wrote: Curiously there is not a big jump in the value of UT2 - A3 at that same date which would have been caused by changing from the old expression for UT2 - UT1 to the new expression. I surmise that this means Stoyko and Guinot did correct the old values of UT2 for the change in that formula. In [https://www.ucolick.org/~sla/leapsecs/taiepoch.html], the table F on page 74 in fact does not show a step in ΔA3 = UT2 - A3 between the lines for 1961 January 00 and January 05 (which is why you could interpolate linearly to obtain UT2 - A3 = -1.4123 s for 1961-01-01). And the column "WWV3" equally shows no step at 1961-01-01, and since it is probably meant to be "BIH integrated atomic time - time signaled by WWV3" (where the latter should include the step down by 5 ms), the point of tabulation "Janvier 0" may actually be the instant when UT2 was 1960 Dec 31 - 5 ms. So yes, the entry may have been "corrected". Anyway, a jump down by 5 ms occurred in (what was later baptized) UTC on 1961-01-01 (see [Explanatory Supplement 1992, p 87]). I always thought that this was done to adapt to the jump in UT2 caused by the change in the formula for UT2 - UT1, but from the graphs in [https://www.ucolick.org/~sla/leapsecs/seasonal.html] (thanks!) I have to conclude that UT2 must have made an upward jump by about 5 ms, while the step by 5 ms in UTC at 1961-01-01 definitely was a downward jump (it is also included as such in the SOFA function iauDat()). Did I make a sign error? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the epoch of TAI, with no more doubt
On 2019-01-21 00:42, Steve Allen wrote: Of course there was a time step. The BIH had to deal with totally hetergeneous data from an ever changing set of contributors. Almost every year for the BIH there was a systematic offset from the times of other years. But until the cesium standard there really is little worth in the absolute values; the importance of the numbers in Bulletin Horaire liese in seeing and understanding the differences between contemporary time services. For the internally used and tabulated time scales, yes, there may be steps, as convenient. But steps in a time scale used to dissmeinate time signals with their own steps and rate offsets are highly inconvenient. I was of the incorrect opinion that the BIH integrated atomic time scale was aligned with the coordinated atomic time scales used by the RGO, NBS, USNO etc since 1960-01-01; but it was not, and only joined on 1961-01-01. Thanks for the corretion! A3 begins 1961-01-01. It does not exist before then. Not even when Guinot re-interpolated all the atomic time scales in Bulletin Horaire ser J no 7 did he extend A3 before then. He introduced his final reconstruction of the old atomic data with It is therefore possible to construct, starting from an arbitrary common origin, scales of Atomic Time ... By that 1966 publication Guinot had ceased to mention 1961-01-01, but linear interpolation of his new A3 tabulation has the value -1.4123 s on 1961-01-01T20, the same as had been used by Anna Stoyko when she re-set all of the BIH atomic time scales. You are of course right; instead of "A3" I should have said "the integrated atomic time scale produced by the BIH for 1957..1960 and which agrees with UT2 at J1958.0", as described on pages 99..101 in [https://www.bipm.org/utils/common/pdf/CC/CCTF/CCDS2.pdf]. From the steps in the WWV time signals as documented in the Explanatory Supplement 1992, p 86..87, I compute a decrease of 1.465 056 s in the WWV time signals against the underlying Cs atomic scale, while this scale ranged over the interval from J1958.0 until 1961-01-01, and this applies to all continuous time scales with the same rate. So, when A3 - UT2 at 1961-01-01 was set to 1.4123 s by the BIH, this must amount to a step of about -53 ms at 1961-01-01 in the BIH integrated atomic time scales before and after 1961-01-01. (And there was no step in UT2 on 1961-01-01.) If this step was done to align A3 with the coordinated times already in use, I am surprised that such a large deviation between integrated atomic clocks could accrue over three years -- A and N Stoyko estimated the deviation after 3 years to be 10 ms in the paper quoted above. Regardless of this difference, there is a thing common to all integrated atomic time scales that suggests that they all are intended to have J1958.0 as their origin: their difference to ET (and later to TT and TDB). In fact, TT - TAI remains very close to 32.148 s, which in turn is close to the value ET - UT2 when UT2 was J1958.0 (but ET - UT2 differs by about 0.5 s for the neighboring years). A step of 0.05 s does not change this property. Guinot also indicates that he retained the jump of 1.6 ms on 1962-01-01 in his new tabulation of A3. These various tabulations deserve to be plotted and examined closely for a step, especially because 1962-01-01 was also the date of the final change in the expression for the seasonal variation of UT2 - UT1. https://www.ucolick.org/~sla/leapsecs/seasonal.html That change should introduce a step of about 6 ms, and this subject is not mentioned in any of the BIH writeups. Do you happen to know in which tabulation the jump by 1.6 ms occurs? A3 minus which other time scale? The 1962 change in the UT2 formula did not apply to prior years; a step in UT2 may have influenced the disseminated time signals which followed UT2, and the step causes jumps in some differences such as A3 - UT2, but it does not not cause a step in UT1 or in any (integrated) atomic time scale. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the epoch of TAI, with no more doubt
On 2019-01-20 17:19, Steve Allen wrote:
Those pages are a response to Recommendation 2 from the second CCDS
meeting held 1961-04-11/1961-04-12. At the CCDS meeting BIH presented
an initial effort to integrate and compare all the cesium standards
for which data were available, and BIH was the only place with the
timing data from all the labs. The BIPM has now scanned and published
the proceedings from all the CCDS meetings, so anybody can look at this.
During those CCDS proceedings is the discussion on what value to give
to an atomic time scale:
The president [Danjon] insists on the need to define a zero, even
arbitrary, for the time scale; it is necessary to date terrestrial
and astronomical events in a certain calendar.
Thanks for the pointer!
Yes, Danjon wants a zero epoch defined, but Markowitz opines that
this is of interest only ("uniquement") for the IAU who should
decide upon it.
The table with the inception of A9 in my web page from Bulletin
Horaire ser 5 no 13 was created scant months after the original
table in ser G no 8. The intro to the A9 table discusses the
difference between the "5 anciens" standards and the 4 new ones.
The intro explicitly states that the BIH is choosing to reset their
value of all these atomic time scales at 1961-01-01T20:00:00 UT2.
But this seems to state something about the inputs for the data
reduction by the BIH. It does not say that the integrated atomic
time scale of the BIH, the BIH output, has had a step at the time,
or a step in rate, or does it?
I understand that the BIH had to adapt every once in a while the
constants for integrating the atomic time scales from their
intermittent comparisons (because of the addition of new clocks,
and because of the increasing accuracy). But I would assume that
the goal in such adaptations must have been to keep the phase and
rate of A3 without any noticeable steps over such a change.
Guinot knew this, in part because after Anna Stoyko decided to create
A3 and sync it with A9 Guinot later re-interpolated A3. More
unquestionably, in Bulletin Horaire ser J no 1 p 3 Guinot wrote
that the origin of A3 and all other BIH TAi values was 1961 Jan 1
and he referred to Bulletin Horaire ser 5 no 13.
Guinot must have known, but in 2004 he said (together with Arias)
that the origin was J1958.0. Couldn't that mean that the change on
1961-01-01 was designed to have no effect on A3 as published by
the BIH?
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the epoch of TAI, with no more doubt
On 2019-01-20 00:50, Steve Allen wrote: I took a closer read and cross reference of the relevant issues of Bulletin Horaire and finalized my web page. The epoch at which TAI was set is definitely 1961-01-01T20:00:00 UT2 Arias and Guinot say in "Coordinated Universal Time UTC: Historical Background And Perspectives", online at [https://syrte.obspm.fr/journees2004/PDF/Arias2.pdf]: "In 1961, the BIH assigned a common origin to these time scales [atomic time A1 of USNO for other integrated atomic times] by coincidence with UT2 on the 1st of January 1958 (Stoyko, 1961). The same origin was used for the BIH mean atomic time." The reference is to: "Stoyko A., 1961, Bulletin Horaire du BIH, Série G, 241-245." That is probably a source you may have access to. The quote implies that the BIH scale A3 (precursor of TAI) was taken to agree with UT2 at J1958.0, but of course this does not rule out that the two time scales also agreed at some later instant. Apparently, the origin J1958.0 was taken retrospectively, and did not just appply to the BIH atomic scales. Since atomic scales had an uncertainty of a few ms per year at the time, it should be possible to verify whether they all agreed at J1958.0 or at 1960-01-01T20 -- it is unlikely that they all ever agreed on more than one instant. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC
On 2019-01-18 17:11, Michael H Deckers wrote: .. insert a step of 0.2 s in their time signal about every 71 days. when he meant "about every 77 days". Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the inception of leap seconds
On 2018-08-15 11:49, Zefram wrote: Time Service Announcement 14 #8 (1971-10-08) discusses the irregular leap (still called a "step") at the end of 1971, but weirdly gives a different size for that step from that which is implied by tai-utc.dat. The announcement states a step size of 107600 us, but the expressions in tai-utc.dat imply a step size of exactly 107758 us. The announcement is The 107758 us computed from tai-utc.dat is in microseconds of TAI, and the leap is only a few nanoseconds shorter in UTC. I cannot explain the -107.6 ms jump of the Announcement; but the 1992 "Explanatory Supplement to the Astronomical Almanac" contains jumps of WWV on p 86..87 that are not in tai-utc.dat. Anyway, I also think that the jump of UTC(USNO) did not happen when TAI was 1972-01-01 + 10 s, as implied by the Announcement, but a bit earlier. See below. . The announcement is ambiguous as to whether this step size is specified in microseconds of UTC or of TAI, apparently ignoring the UTC frequency offset for this purpose, though the offset isn't anywhere near big enough to account for the discrepancy. While UTC is defined to be a piecewise linear function of TAI, the practice was (and still is) to specify TAI - UTC (and thus TAI) as a piecewise linear function of UTC. The "steps" specified in Bulletin C are steps in TAI - UTC, hence also of TAI, as a function of UTC -- which probably is what you mean by "microseconds of TAI". Time Service Announcement 14 #8 of 1971-10-08 is no exception: it gives TAI - 10 s - UTC(old) as maintained by the USNO as a function of UTC(old), where UTC(old) is the unique linear extension of UTC as defined directly before 1972-01-01. Thus, the member 2 592 (MJD - 41 317) has to be read as 2 592·(UTC(old) - 1972-01-01)/(1 d). The inverse relation to UTC as a function of TAI is not a function: UTC assumes some values twice, for different values of TAI (when UTC makes a jump down); and UTC did not assume some values (when UTC made a jump up, as it last did around 1968-02-01). So TAI is a sometimes two-valued (positive leaps) and sometimes undefined (negative leaps) "function" of UTC, and it is not always clear where it differs from the function TAI of UTC that is officially specified. The discontinuity of UTC near 1972-01-01 is an exception because the jump up of TAI - UTC from 9.892 242 s to 10 s was accompanied by a jump in the (piecewise constant) rate d(TAI)/d(UTC) from 1 + 2.592 ms/d down to 1 (the only case where both TAI - UTC and d(TAI - UTC) have been discontinuous). Here we do know that a jump of UTC from 1972-01-01 to 1972-01-01 - 0.107 758 s must have happened when TAI was 1972-01-01 + 9.892 242 s. At any other value of TAI between 1972-01-01 + 9.892 242 s and 1972-01-01 + 10 s, the jump in phase would have been by a different amount, and not by an integral multiple of 1 µs. HTH Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
On 2018-07-20 18:05, Stephen Scott wrote: While there is no perfect answer, it seems that Microsoft Azure servers got it right for the last one, incorporating the leap second just before midnight local time. No, they didn't. A leap second describes a discontinuity in the function TAI - UTC. For the last leap second, the value TAI - UTC was 37 s since TAI was 2017-01-01T00:00:37, and for some time before that, it was 36 s until TAI reached 2017-01-01T00:00:36. The standards do _not_ say when exactly TAI - UTC switched from 36 s to 37 s, but it must have been between the TAI values 2017-01-01T00:00:36 and 2017-01-01T00:00:37, inclusive, as can be inferred (perhaps with some good will) from IERS Bulletin C52 of 2016-07-06 (the official specification of this leap second). The time interval between these TAI values (excluding the TAI value 2017-01-01T00:00:37) is called a positive leap second; the corresponding UTC values are denoted (in ISO 8601 format) with second values >= 60 (as specified in ITU-R TF.460-6 of 2002). This is true everywhere near the surface of the Earth, even for Kiritimati. So Kiritimati had its last leap second when every other location on the Earth had it, that is, when TAI went from 2017-01-01T00:00:36 to just before 2017-01-01T00:00:37, and UTC went from 2016-12-31-23:59:60Z to just before 2017-01-01T00:00:00Z; so that local time went from 2017-01-01T13:59:60+14 to just before 2017-01-01T14:00:00+14 during that leap second. HTH. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Windows Server 2019
what looked like a politically expedient shortcut which was full of unexplained technical complexities. It is not clear who can remedy things. I do not take such a grim view of the history of UTC. It is certainly true that (international) commissions do not always work efficiently and unbiased, and that powerful people like Gernot Winkler can have a dominating influence on their decisions. But there was general agreement in 1970 that the rates of UTC and TAI should be made equal, and the only realistic alternative to the leap second proposal at the time would have been to make UTC a fixed translate of TAI -- which would have been the greater change to existing practice. No wonder that no alternative to Winkler's UTC was proposed. And one also has to admit that the 1972 definition of UTC has been remarkably successful: arguably all countries now use UTC as their basis for legal time, and many even formally admit that they do so; UTC is used globally to date all kinds of observations in astronomy, geodesy, meteorology, space technology; and it is widely taken as the time base for computers. The previous time scale definition that lasted for more than 50 years was that of UT, defined by Newcomb in terms of Greenwich mean sidereal time. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Question about UT1 and the IERS Reference Meridian
On 2015-04-30 01:01, Mike Lawson wrote: So, what I take from this is, 1) UT1 (and hence UTC) is based on the International Reference Meridian, not the Prime Meridian (Greenwich). No and yes. In 2000, the IAU has decided that UT1 (since 2003) measures the angle between the "Terrestrial Intermediate Origin" TIO and the "Celestial Intermediate Origin" CIO. Both points lie on the equator of the intermediate pole of rotation (CIP), whose position moves both relative to the Earth's surface and the celestial sphere. The TIO also moves on the Earth, and even though this method of determination of UT1 is called the "method of non-rotating origins", the points TIO and CIO _do_ rotate secularly. (The reason for this choice of the TIO is the decision that rotations of the CIP on the Earth should not affect the Earth rotation angle. The disadvantage is that the value of UT1 at any time depends on all prior movements of the CIP.) So, conceptually, UT1 is _not_ based on the International Reference Meridian, but on the point TIO that differs from it by the "TIO locator" s' which increases over time. On the other hand, the rotation of the TIO on the Earth is very slow, about 15 µm/a on the equator. Hence the IAU could state that "UT1 is considered to be nominally equivalent to mean solar time reckoned from midnight on the meridian of Greenwich". Thus, numerically, you are right. While the IERS Conventions describe all this at length and in all numerical detail, the concepts involved and the underlying geometry are better explained in other sources. An excellent short account by Nicole Capitaine and Patrick Wallace is at [iau-c31.nict.go.jp/pdf/2009_IAUGA_JD6/JD06_capitaine_wallace.pdf] Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] final report of the UK leap seconds dialog
On 2015-02-05 11:16, Peter Vince wrote: Yes, I took part in the initial meeting of "professionals" (so-called "stakeholders"), where the issues were indeed thoroughly discussed, and well understood (apart from some unfortunate absences - no-one from the military was there, for example). But on the video on the linked page below, nine members of the public gave their views, one of them said "If it's not broke, don't fix it", and two others said they didn't understand what the fuss was all about - it's been working OK for the last 25 times. (And none of the nine people were in favour of changing the system.) I would sympathise with both those views, but they seem ill-informed: I believe this discussion has come about exactly because it *is* broken, and *hasn't* been working perfectly for the last 25 times. None of the people interviewed had even heard of leap-seconds - clearly the stories about the long delays at Sydney(?) last time because of the Quantas problem were too far away to register with them. That's all fine, *we* were busy managing the problem so the rest of the world didn't have to worry - as it should be. But as I said before, I am disappointed that those members of the public were left with the impression that there is nothing wrong, and we timekeepers just want to change things for the sake of it. But where is the detailed list of the problems with the current version of UTC, where is the analysis of this list, and the exploration of the solution space? Take for example the bad predictability of the current UTC, brought up repeatedly by Warner Losh. This could perhaps be alleviated by a long term specification of future leap seconds -- but this is apparently not even discussed by the ITU experts for Study Question ITU-R 236/7. It is exactly this lack of due engineering process that leads to the "if it ain't broke" position. And if the WRC votes for abandoning leap seconds, we would not know whether the IERS will continue to publish DUT1, or whether the BIPM will revoke TAI. I do not find it the least bit surprising that most average citizens oppose such a change. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] [QUAR] Bulletin C and all that
On 2015-01-26 20:05, Brooks Harris wrote: As a practical matter of modern timekeeping the UTC timescale started at 1972-01-01T00:00:00Z (UTC). NTP, POSIX, 1588/PTP and others refer to epochs and timescales they call "UTC" that occur earlier than 1972-01-01, so this confuses matters. But those epochs exist on "Gregorian calendar timescale that is proleptic to the UTC origin", not on the modern UTC timescale proper. We've got to get past this confusion. A calendar provides a method for denoting datetime values. A time scale is a coordinate function within coordinate systems for physical (astronomical) models that assigns datetime values to each point in its domain of definition. Hence a calendar should not be confused with a time scale, even if the calendar is used exclusively for the notation of the values of a single time scale (which is not the case for the Gregorian calendar). Values of the time scale later called UTC by the BIH can be exactly related to TAI since 1961, see [hpiers.obspm.fr/iers/bul/bulc/UTC-TAI.history]. Steve Allen's Time Scales page points out - Time Scales http://www.ucolick.org/~sla/leapsecs/timescales.html "Nothing resembling the name UTC was used prior to 1960, so any claim that UTC can be used before then is inappropriate. The name UTC did not appear in any official context until 1974, so any claim that UTC was used prior to 1974 is almost certainly a reinterpretation of history which does not correspond to anything in contemporary documents." The history is tangled, but none of it matters except to historians. I think that "1974" is just a typo for "1964"; I do not see any error in the history. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Bulletin C and all that
On 2015-01-25 14:58, Rob Seaman wrote: Please let me know about typos, suggestions, etc. Needless to say this > remains a prototype. ... MM before after encoded crc IP Decodedflags > -- 1972 1 9 10 f8000a00 f5 248.0.10.245-> OK 1972 1 10 1 (1, 0) It would be incorrect to consider the discontinuity of the difference TAI - UTC at the epoch when TAI was 1972-01-01T00:00:10 as a leap second; the difference increased by about 0.108 s, not by 1 s. Hence, a timestamp such as "1971-12-31T23:59:60.2Z" should not be made acceptable. The first leap second occurred when UTC reached 1972-07-01; the information about a leap second says something about TAI - UTC both before and after the date referenced. At 1972-01-01, however, the information can only say something about TAI - UTC for TAI on or after 1972-01-01T00:00:10, but nothing (correct) for smaller values of TAI. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-04 22:26, Steve Allen quoted Bernard Guinot about the unit for the difference TAI - UT1: Guinot explained this using the term "graduation second" in section 2.2 of 1995 Metrologia 31 431 http://iopscience.iop.org/0026-1394/31/6/002 He points out that the way the IAU has written the definitions of the time scales uses a subtly ambiguous notation. He writes The numerical value of UT1(IERS)-TAI does not of course, express a duration. In this context, the "s" only conveys the information that the readings of the two time scales are expressed in graduation seconds. Guinot comes back to this question, and revises his position, in [Guinot 2011, section 7.a, p 4139], where he exposes the underlying fundamental question: how can the set of spacelike and timelike coordinates be given consistent dimensions (invariant under the Minkowski group). He writes: (a) Unit of relativistic coordinates Some authors consider the relativistic coordinates as dimensionless, others give a special name to their unit, such as the ‘TCB second’ or a global name such as ‘graduation unit’. I was myself in favour of the latter name. However, after long discussions with eminent metrologists, Quinn and de Boer, I agreed that it was simpler to name ‘second’ the graduation unit. Thus, more generally, all quantities having the dimension of time have the second (without any qualifier) as their unit, even if they have different natures, such as time interval and reading of a time scale. If the logic of this point of view seems rather obscure, then it is possible to consider it as a convention which has the merit of being in agreement with the quantity calculus. It also agrees with the metrological rule that the unit does not define a quantity. While I can only agree with Guinot's position, I am not sure whether space coordinates and relativistic change of coordinates can be modeled neatly in that way. Amazing that simple questions about time scales can lead to such really fundamental conceptual issues! Reference: [Guinot 2011] Bernard Guinot: "Time scales in the context of general relativity". in: Philosophical Transactions of the Royal Society A. vol 369 p 4131..4142. 2011-09-19. online at: [rsta.royalsocietypublishing.org/content/369/1953/4131.full.pdf] Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-06 13:10, Steffen Nurpmeso wrote in defense of the description by the German metrology laboratory in [https://www.ptb.de/cms/en/fachabteilungen /abt4/fb-44/ag-441/coordinated-universal-time-utc.html]: Hm, indeed a sloppy translation of the original German text Die Einführung der Zeitskala UTC geht auf Vorschläge des CCIR (Comité Consultatif International des Radiocommunications) zurück which is more like "Introduction of the time scale UTC originates in suggestions made by..". But the German text is equally wrong. The CCIR was tasked to find a common time scale for radio dissemination, but they did not "suggest" the underlying concepts of UTC. The concepts were developed about 1960 within the RGO, NPL, USNO and the BIH, at a time when time determination meant the reduction of UT0 to UT1, and a common reference time scale with rate close to UT2 was an enormous help. But of course passion can't be replaced by anything else. Maybe money? I do not see which point you want to make here. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-05 16:27, Zefram wrote: ... UTC is always an integral number of seconds offset from TAI, and so by construction UTC(NPL) is always an integral number of seconds offset from TAI(NPL). Hence each of the marks also occurs at the top of a second of TAI(NPL). The symbol TAI(k) is defined in RECOMMENDATION ITU-R TF.536-2: Time-scale notations of 2003 with the text: TAI(k): Time-scale realized by the institute “k” and defined by the relation TAI(k) = UTC(k) + DTAI, where DTAI is the number of integral seconds specified by the International Earth Rotation Service (IERS) as being the difference between UTC and TAI; I do not know whether that notation has ever been put to serious use outside this recommendation. The contributions by the various metrology institutes to TAI are independent from the UTC(k) and are denoted by TA(k) in Circular T by the BIPM. The recommendation explains it as: TA(k): Atomic Time-scale, as realized by the institute “k”; Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-05 11:28, Steffen Nurpmeso wrote: Oh, the German Physikalisch-Technische Bundesanstalt (PTB) also has a general -- at least -- overview of the set of problems. (English: [1] and all around that; oops, not everything is translated, what a shame! I hope it's not due to lack of resources, which seems to become notorious in Germany [for things that really matter at least].) .. [1] <https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-the-si-second.html> Rest under <https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of-legal-time-in-germany/> The very beginning of the last reference is misleading and wrong: "Properties of UTC The time scale UTC (Coordinated Universal Time) owes its existence to the CCIR (International Consultative Committee of Radiocommunications) of the ITU (International Telecommunications Union) which proposed to broadcast time signals worldwide in a "coordinated" way, i.e. by reference to a common time scale." The concept for UTC was devised by people from the BIH and some other metrology institutes, not by the CCIR; and the CCIR has never produced a time scale. It is unfortunate that most sources about time and time scales are full of inaccuracies and errors like these, perpetuated through hundreds of papers and books. Steve Allen's page [http://www.ucolick.org/~sla/leapsecs/timescales.html] gives a carefully researched, reliable account of the history of UTC and other time scales, based on the primary sources. It is the result of an enormous labor in extracting the facts from a mixture with myth and hearsay. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-04 22:26, Steve Allen wrote: Guinot explained this using the term "graduation second" in section 2.2 of 1995 Metrologia 31 431 http://iopscience.iop.org/0026-1394/31/6/002 He points out that the way the IAU has written the definitions of the time scales uses a subtly ambiguous notation. He writes The numerical value of UT1(IERS)-TAI does not of course, express a duration. In this context, the "s" only conveys the information that the readings of the two time scales are expressed in graduation seconds. Thank you for that information! Yes, not every quantity with dimension time is a duration, let alone a duration of proper time. The difference between clock readings need not relate to proper time, and not even to the same time scale. A few operations with durations of differing time scales are considered to result in durations (eg, a weighted average of durations measured in different time scales), but most can not. And a sedimentation rate (a quotient velocity/acceleration) can not be considered as a duration, nor as the result of any other operation with time scales. Nevertheless, all these quantities have the dimension of time and can therefore be expressed with the SI unit for time, even though the SI second is (currently) defined as a duration of proper time. This is essential for the meaningful operations that one wants to perform with these quantities (differences of clock readings, averages of durations), but it also makes many meaningless operations possible (such as subtracting a sedimentation rate from a clock reading). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-04 19:45, Brooks Harris wrote on the history of UTC: For purposes of astronomy, and probably others, the "rubber band era" may have relevance. To call it "UTC" seems a bit of a stretch to me, but there's no generally accepted name for what Zefram calls "rubber-seconds era of UTC". An excellent account of the political and technical history of UTC is on Steve Allen's page [http://www.ucolick.org/~sla/leapsecs/timescales.html#UTC]. For instance, it tells us that official use of the term "UTC" dates from 1964. The informal term "UTC with rubber seconds" is intended to refer to the time when the rates of UTC and TAI differed (before TAI reached 1972-01-01 + 10 s). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-04 12:34, Zefram wrote: UT1 always ticks a second for that ERA increase, but Warner's point is that the second of UT1 isn't an *SI* second. The time taken for that ERA increase, and hence the duration of a UT1 second, very rarely exactly matches an SI second. The second of UT1 is an angular unit, defined as 1/86400 circle (= 15 arcseconds), not a unit of physical time. Then which unit would that be? When the IERS compute a difference TAI - UT1, how do they do it? Do they convert the UT1 reading in any way before they subtract? Or, if they don't, what is the unit of the difference, SI seconds or "second of UT1"? The IERS Conventions certainly do not mention any of this. How could they if the units would really differ? Of course, due to the history, we alias angular seconds to physical seconds all over the place, especially in the mathematical expressions that we use to describe relationships between time scales. Usually we gloss over that by just calling them both "second". But if you're going to specify which type of second you mean, better pick the right one for the time scale. I am puzzled by the fact that some people do not seem to accept with time what they easily accept with other quantities. For instance in geodesy, normal height is expressed in meters (or feet) even though it is actually a difference in geopotential observed by leveling. The expression in meters is derived from some conventional "normal" gravity potential model; comparison with orthonormal height thus gives an intuitive notion of its deviation from the real gravity field. But nobody calls for different units for orthometric and normal heights, on the grounds that a meter of normal height would not be an "SI meter" of "real length" while a meter of orthometric height would be. On the contrary, everybody agrees that normal and orthometric height must use the same unit so as to make them comparable. (And, as with time scales, there is a bunch of other important notions of height to which they need to be compared!) The mean solar day on the rotating surface of the Earth is given by the comparison of UT1 with TAI (or TT). Its value, d(TAI)/d(UT1)·(86 400 SI seconds) would be a bad unit of time because it varies remarkably with time. And the mean solar day in a geocentric "inertial" system (as used in satellite dynamics) is a different value altogether, namely d(TCG)/d(UT1)·(86 400 SI seconds) at the geocenter. Neither quantity is used as a unit to express UT1; instead, both are derived from expressions of UT1, TAI, and TCG in SI units. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-02 19:04, Warner Losh wrote: On Nov 2, 2014, at 11:21 AM, Michael Deckers via LEAPSECS wrote: For instance, the differential rate d(TAI - UT1)/d(UT1) is published as LOD by the IERS as a "dimensionless" number with unit ms/d. To compute this, one must be able to subtract the reading of UT1 from that of TAI, and to compute the difference numerically one has to convert to equal units. The rate is computed correctly /only/ if one assumes that a second of TAI equals a second of UT1. This isn’t entirely true. You have to compute the length of the different time scales to the same seconds. You can compute the difference by comparing the clock readings at a fixed point in time after interpolation to a common grid. This will give you the difference in terms of the units of the common grid. If you select UT1 as the common grid, then you can also get a rate to come up with the unit less number. Thanks for your reply. If I understand you right you are saying that comparisons require the same time unit being used in the expression of the time scale values. I agree. But I must confess that I do not understand your use of "grid". Time scales are quantities whose values can always be expressed as a sum fundamental epoch + a time value, the latter expressed in a common time unit. The difference between the values (= phases) of two time scales at the same point in spacetime thus is just the sum of the difference of their fundamental epochs plus the difference of their time values (both differences are again time values). And if I compare the rates of the two time scales, then the fundamental epochs used to express the values of either become irrelevant because they are fixed for each time scale. I am not sure which common grid is needed here. You can also compute the frequency ticking of each time scale in terms of one or the other (or a third independent one) to compute the frequency error of one or both of the time scales. Once you have a frequency error (or difference), conversion of units is trivial. This is more likely how the LOD drift number is computed. It’s how you compare different atomic clocks to say this one is slow, that one is fast and assign a frequency error to each one (and a similar construct to assign the phase error of the PPS each one is producing). ... Yes, measuring the differential quotient d(TAI)/d(UT1) and measuring the "drift rate" LOD = d(TAI - UT1)/d(UT1) = d(TAI)/d(UT1) - 1 are obviously equivalent. .. There are a variety of ways to measure these differences (though UT1 something has to involve astronomy since it is an observational time base) and compute these numbers. Well, most time scales are observed, directly or indirectly -- just the relationships TCB <-> TDB and TCG <-> TT are fixed, and UTC and the many civil time scales are determined by fiat. Also, UT1 were ticking in SI seconds, there would be no rate difference. :) No. The unit used to express the values of a time scale does not determine the rate of the time scale. UT1 is a timescale that ticks 1 SI second when the Earth Rotation Angle increases by exactly (2·π rad)/86 636.546 949 141 027 072, and TCB ticks 1 SI second when proper time at the barycenter of the solar system increases by 1 SI second. Each of these time scales is defined or extended to the geoid where their rates differ from that of TAI. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the big artillery
On 2014-11-01 23:31, Steve Allen wrote:
In the appropriate contexts there are days of Terrestrial Time,
International Atomic Time, Barycentric Coordinate Time, Geocentric
Coordinate time, GPS system time, BeiDou system time, etc. Each of
those days is 86400 SI seconds in its own reference frame.
In other contexts there are days of Universal Time, Sidereal Time,
Ephemeris Time. Each of those days is 86400 of its own kind of
seconds.
I disagree. One wants to compare all these time scales with
each other, and comparison requires expression in the
/same/ unit, not in different units.
For instance, the differential rate d(TAI - UT1)/d(UT1) is
published as LOD by the IERS as a "dimensionless" number
with unit ms/d. To compute this, one must be able to
subtract the reading of UT1 from that of TAI, and to
compute the difference numerically one has to convert to
equal units. The rate is computed correctly /only/ if
one assumes that a second of TAI equals a second of UT1.
I agree that it can still make sense to use different
symbols for the same unit (such as s{TAI} and s{UT1});
it is similarly common practice to distinguish masses
of carbon dioxide from masses of carbon by different
unit symbols g{CO₂} and g{C} for the same unit gram.
Nevertheless, the BIPM seem to advise against such use
[SI brochure 2006, section 5.3.2, p 132]:
Units are never qualified by further information
about the nature of the quantity; any extra
information on the nature of the quantity should
be attached to the quantity symbol and not to the
unit symbol.
Reference:
[SI brochure 2006]:
http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] presentations from AAS Future of Time sessions
On 2014-01-12 03:28, Brooks Harris quoted from RFC 5905: Then, and very importantly, Figure 4: Interesting Historic NTP Dates states the relationship to "First day UNIX" - +-++-+---+--+ | Date| MJD| NTP | NTP Timestamp | Epoch| | || Era | Era Offset| | +-++-+---+--+ | 1 Jan -4712 | -2,400,001 | -49 | 1,795,583,104 | 1st day Julian | | 1 Jan -1| -679,306 | -14 | 139,775,744 | 2 BCE| | 1 Jan 0 | -678,491 | -14 | 171,311,744 | 1 BCE| | 1 Jan 1 | -678,575 | -14 | 202,939,144 | 1 CE | | 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian | | 15 Oct 1582 | -100,840 | -3 | 2,874,597,888 | First day| | || | | Gregorian| | 31 Dec 1899 | 15019 | -1 | 4,294,880,896 | Last day NTP Era | | || | | -1 | | 1 Jan 1900 | 15020 | 0 | 0 | First day NTP| | || | | Era 0| | 1 Jan 1970 | 40,587 | 0 | 2,208,988,800 | First day UNIX | | 1 Jan 1972 | 41,317 | 0 | 2,272,060,800 | First day UTC| | 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th| | || | | Century | | 8 Feb 2036 | 64,731 | 1 | 63,104| First day NTP| | || | | Era 1| +-++-+---+--+ Please note that this table has to be read with caution. Besides the typo -678,491 for -678,941, one has to realize that "1 Jan -4712" is meant as a date in the Julian calendar, but all the other dates in column 1 must be taken as Gregorian calendar dates, even those before 1582-10-15 -- else the entries in columns 2,3,4 become incorrect. And this makes the entry in column 5 for the date 1582-10-04 incorrect. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] drawing the lines
On 2013-04-30 13:26, Rob Seaman wrote: On Apr 29, 2013, at 1:25 PM, Tom Van Baak wrote: I reject the notion that UT1 is "angle" and UTC is "time". Then you reject Recommendation CCTF 6 (2012): http://www.bipm.org/utils/common/pdf/CCTF19.pdf In the meeting report of the CIPM of 2012, online at [http://www.bipm.org/utils/en/pdf/CIPM2012-EN.pdf], these recommendations apparently are taken with a grain of salt, after "comprehensive discussion". On [page 60] we read: "It was further noted that the CIPM must respond to the ITU although it was not necessary to agree to Recommendation CCTF 6 (2012)." Recommendation CCTF 6 (2012) was not accepted by the CIPM, but it was taken note of. Nevertheless, the CIPM noted several "points" that also may be contentious, such as: "The ITU requires clear advice on how to build a continuous time scale." -- as if the ITU had ever "built" a time scale. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] trivia, the 2nd longest year
On 2012-04-12 19:33, Steve Allen asked: A well circulated piece of trivia is that 1972 was the longest year in recorded history because civil time contained two leap seconds. I offer this challenge: What was the second longest year in recorded history, and how many leap seconds did it have? After 1972, UTC was never delayed against TAI by more than 1 s per year. And before 1972 (and after 1960 when UTC was started), this happened only once, in 1971, when UTC was delayed against TAI by 1.053 838 s (the rate d(TAI)/d(UTC) was 1 + 2.592 ms/d at that time). But of course, this does not answer your question because during "the year" 1971 (the time when UTC indicated 1971, plus the time span of about 107.757 997 ms in UTC when UTC was >= 1972 but before TAI reached 1972 + 10 s), TAI only gained about 365 d + 1.05 s which is nearly a day less than what TAI gains in any leap year of UTC. So the expected answer probably is any leap year > 1972 with a positive leap second (1976, 1992, 2008, 2012), where one may even remark that, in terms of the TT time scale, 2008 and 2012 are slightly longer than 1976 and 1992, and that 2012 may not belong to recorded history yet. Or you mean a year before 1960 but then it is not clear to me which time scale you use for determining the years (instead of UTC) and which to measure their lengths (instead of TAI). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] The ends we seek
On 2012-01-21 01:36, Mark Calabretta mentioned correct implementations of leap seconds: Try Tom's leapsecond.com, you can watch the next one in real time. Only 161d 23h 23m 42s to go - tick, tick, tick,... Yes, this is very impressive! I wonder whether Tom Van Baak uses any C or Java or perl or.. functions to get current UTC. Thanks! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 23:27, Poul-Henning Kamp remarked: This is not a current standard C interface, this is *new* C interface that does it right. Ooops, sorry! I overlooked that. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 18:58, Poul-Henning Kamp asked: Why on earth would you even want to specify a difftime ? Because it is required by standard C? If you do not want to conform to standard C then you are designing new language and can of course do anything you like. But getting it into Standard C will be hard -- it has been tried on several occasions without success. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 15:54, Poul-Henning Kamp wrote: timeval contains bogus combinations of tv_sec and tv_usec and a lot of code does not even notice... Yes, in contrast to IEEE binary floating point values where each and every bit pattern belongs to one of the classes FP_INFINITE, FP_NAN, FP_NORMAL, FP_SUBNORMAL, or FP_ZERO. I already specified that you get EINVAL if it is not a valid floating point number. I may have to be more specific than "valid" but I really don't see this a problem, considering how trivial and fast this is to check, compared to the math needed to get to, for instance UTC. Yes, a specification had to clarify what the term "valid floating point number" means. More to the point: IEEE arithmetic adheres to a well-defined (and sophisticated) computational model, and I believe users would expect that model to be followed if time_t was an IEEE float. Case in point: difftime() should react in the standard way on arguments that are signalling or quiet NaNs -- even if the programers don't care or don't know, their debuggers may rely on it. Of course, you are right that all this can be reasonably specified (with some effort). May be this is what BSD users REALly want to be in (or in ). You probably know best how to find out. > Moreover, IEEE floating point operations depend on certain > environmental settings (eg, rounding modes and enabled > traps) and it is not clear whether a system call must or > can use those of the caller in every circumstance. I'm not sure I can see how it can become relevant, given a good quality library implementation. Example questions: does difftime() set the inexact flag? does it use the rounding mode in force at the call? (People do interval arithmetic by executing their algorithm twice with different rounding modes.) Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-21 12:31, Poul-Henning Kamp wrote in reply to comments on his proposal for time_t as 128 bit binary float: First of all, I'm not particular wild about floating point numbers, but the fact of the matter is that: A: Time is measured in seconds, with a fractional part. B: We want a datatype which supports normal sums and differences. Both of which point to a floating point format, where operations will naturally do what people expect from them. And there is prior art: in the Apple Mac OSX operating system, the system call CFAbsoluteTimeGetCurrent() returns time as seconds since 2001-01-01 as a double value. When timestamps of computer operating systems are used to represent the physical time (of the call), a floating point representation is a good choice, so I do not want to argue against it. I just think that the additive structure of IEEE float values is much more involved than the additive structure of timespec and timeval. For one thing, IEEE float values contain infinities and NaNs, and since the POSIX interfaces accept time_t values as inputs, ths system code would have to deal with them. Moreover, IEEE floating point operations depend on certain environmental settings (eg, rounding modes and enabled traps) and it is not clear whether a system call must or can use those of the caller in every circumstance. A temporary switch in these settings may be needed. The timestamps of computer operating systems are often used in a way where mainly the sequence of increasing values is important, not so much their absolute value. Comparing IEEE floating point values holds its surprises because values may be incomparable, or can compare equal and still be distinct, and the conversion to and from a decimal notation of a binary floating point value is no easy matter if it is supposed to strictly preserve order. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Lets get REAL about time.
On 2012-01-20 15:46, Gerard Ashton wrote: For the smallest time resolution required, we might suppose that at some point in the future there might be a need to account for transmission delay from one part of a computer to another. The smallest location that I can imagine being of interest even in a future computer is the diameter of a hydrogen atom, about 0.1 nm. The time for light to travel this distance is about 3 as, or about 2^-58 s. Just a correction on your arithmetic: light travels at 0.3 m in 1 ns, so it takes only about 0.3 as for the distance of 0.1 nm, not 3 as. To set the scale, the finest resolution possible with the time of day register in IBM zArchitecture machines is 2^-52 µs =~ 0.2 zs, which is 3 orders of magnitude below your proposal. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ISO TC 37
On 2012-01-18 23:33, Tom Van Baak proposed: I would like at some point, regardless of how the ITU vote turns out for this list to collectively work toward external education rather than internal bickering or google baiting. For every one of us there are a thousand engineers out there who are clueless about the subtleties of timescales. We could all work together on a best practices document. In particular, it seems to me many of your telescope concerns would be non-issues if you could use your influence to push the use of UT1/DUT1 in those systems related to pointing. Good idea. This is actually a policy of the BIPM: every new definition is to be supported by a "mise en pratique" (guide for the practical use). I suggest we need such guidance not only in time before UTC is redefined, but also for the use of the current definition of UTC in electronic information networks and in programming interfaces. Having both guides could make the decision in 2015 even more rational. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Germany supports UTC as we know it
For those who read German: "Und auch Deutschland wird nach Auskunft des Bundeswirtschaftsministeriums, wo die deutsche Position bestimmt wird, für den Erhalt der UTC und der Schaltsekunde plädieren, wenn es zur Abstimmung kommt." (And Germany will also plead for the preservation of UTC and the leap second, if there is a vote, according to information from the federal ministry of economy which decides the German position.) Full story at [http://www.faz.net/-gqz-6wtrw]. Interestingly, Andreas Bauch, a chief scientist at the German metrology institute, PTB, is quoted as being in favor of a continuous civil time without leaps, but not under the name UTC. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] draft revision of ITU-R TF.460-6
On 2011-12-08 18:50, Steve Allen sent the link: http://www.ucolick.org/~sla/leapsecs/draftTF460-7.html Thanks. Three new(?) points I find quite revealing The ITU-R propose to note: [k] that the IERS provides predictions of the difference between UT1 and UTC at different delays, which allow real-time access to UT1, and which will on average over a two-year period provide a more accurate knowledge of UT1 than does UTC with leap seconds, So by abolishing leap seconds, we get a better approximation of UT1? This better approximation is already available today, without any help of the ITU. Should we be grateful to the ITU-R that they don't take it away after they have taken away leap seconds and DUT1? The ITU-R propose to recognize: [6] that celestial navigation is no longer a primary means of navigation; thereby suggesting that UTC need no longer be suitable for celestial navigation. This is sarcastic! Celestial navigation today is the very last resort when everything else fails. The time scale disseminated world wide must remain usable for celestial navigation. And the ITU-R, as a UN body, should recognize this. The ITU-R propose to state: [B] TAI is not physically realized and consequently is not suitable for time dissemination. (It appears that this argument has originally been raised by people from the BIPM.) So what do all these clocks contributing to TAI measure when TAI is not "physically realized"? And why is TAI "not suitable for dissemination" even though TAI - 35 s apparently is? This is all sheer nonsense. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] BBC article
On 2011-11-15 16:44, Warner Losh wrote: It is disheartening that the middle ground remains unexplored. Most of the difficulty of the current system could be solved by allowing DUT1 to grow as large as 10s, but still keep it bounded. But this "difficulty" never has been the concern of ITU-R! Their concern very clearly is the non-monotonicity of UTC and the proliferation of different ad hoc time scales invented to overcome the discontinuity of UTC at leap seconds. Changing the schedule of leap seconds would not reduce the need for UTC-SLS, Google time, UTC[SOFA],..., nor the number of schemes for mapping UTC values around leap seconds to time_t values in the various UNIX flavors. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] WP7D document on UTC
On 2011-11-01 18:31, Steve Allen wrote: One of the contributors to futureofutc.org alerted the chairs that during our meeting the ITU-R issued a document for WP7D. http://www.itu.int/oth/R0A0809/en It has news about UTC, and among other things it indicates the response to CACE 539. To date, the BR received replies from 16 different Member States for the latest survey (out of a total of 192 Member States, 55 of which participate in the formation of UTC) - 13 being in favor of the change, 3 being contrary. apathy? not wanting to be the daisy standing tall enough to be lopped off? The document says that "spectrum utilization" is an important concern of ITU-R. No wonder they care so much about the 10..100 nHz band with all that leap second cross talk! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap smear
On 2011-09-20 17:08, Steve Allen wrote: At the CCIR Plenary Assembly in 1978 when CCIR Rec. 460-2 were published the supporting documentation literally rejoices at the 1975 CGPM resolution which says that UTC is mean solar time. Interesting. Did they really think the CGPM said that "UTC is mean solar time"? Of course, the CGPM never said that. They "considered" in 1975 that the "system called 'Coordinated Universal Time' (UTC)" -- they did not call UTC a time scale -- "makes available to the users" "an approximation to Universal Time (or, if one prefers, mean solar time)". Note that the definitive French version is unambiguous; in French the quote reads: "une approximation du Temps universel (ou, si l’on préfère, du temps solaire moyen)" implying an "approximation .. to mean solar time". This statement of CGPM is just a conjunction of two statements, which were true at the time: - UTC is approximation of UT1 - UT1 could be considered as mean solar time. The first statement remains true even with the proposed redefinition of UTC (just with a worse approximation than the one used in 1975). The second statement may not be true with the current definition of UT1, simply because no mean sun has been defined for the current UT1. If one prefers to call the current version of UT1 a mean solar time then this is only justified as far as UT1 has agreed in phase and rate until 2003 with the mean solar time as defined in 1978 and before. The current UT1 is better called Earth rotation time. It is well-known that the "non-rotating origins" of UT1 rotate and thus the current UT1 differs secularly from mean solar time. The current definition of UT1 makes it not only dependent on the attitude of the Earth in space, and on (a bounded function of) the position in its orbit, but also on the past movements of the pole of rotation, on which mean solar time in any reasonable definition does not depend. But then -- UT1 will certainly be redefined, at the latest when the increased accuracy of its determination makes the "non-rotating origins" impracticable. It might even become mean solar time again. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap smear
On 2011-09-18 17:14, Joe Gwinn wrote: The handling of leap seconds is not defined in POSIX, which does not apply leap seconds. POSIX requires that the time_t value returned by time() had to increase by 3 while UTC increased from 2008-12-31T23:59:58 to 2009-01-01T00:00:01. This interval included a leap second and was 4 s long, so POSIX arguably must "apply" leap seconds. Moreover, different flavors of UNIX press these 4 s into 3 units of time_t (and timeval or timespec) in different ways, as a monotone and continuous function of TAI. ... The result is that the handling of leap seconds depends on some combination of the GPS timeserver providing UTC to the computer, [and] the operating-system kernel implementation. Yes. My point is that POSIX fails to give guidelines on how to make these time_t (and timeval or timespec) values precisely understandable to applications, and comparable across systems. Currently, only struct tm values can be used for that purpose. No wonder some people want to eliminate future leap seconds -- this would also remove all those problems. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] leap smear
On 2011-09-16 22:46, Daniel R. Tobias observed Google's lack of compliance with international standards: On 16 Sep 2011 at 10:54, Poul-Henning Kamp wrote: > Well, Googles hack is a workaround for internal use with no regard > to subsecond interoperability with anybody else. That's typical of Google's general philosophy, where they value their services functioning smoothly over strict compliance with external standards; for instance, "web purist geeks' find it infuriating that Google's HTML fails to validate, but they're more interested in shaving off a few bytes by doing things like omitting quotes around attributes even where the standards require them, so long as all known browsers render the page correctly. There simply is no standard modification of UTC that is a monotone function of TAI, and which is N times continuously differentiable for some N >= 0. Instead, there are several such modifications, used or propsed, such as Google's, the SLS time scale of Markus Kuhn, the modification in SOFA, and the time_t values in UNIX-like operating systems, each especially designed for their usage. Google needed a modification of UTC that could be used as the steering input for an ensemble of clocks. This requires a signal that is at least two times differentiable, like the signal of a clock that is not subject to sudden changes in rate. I find it clever from the Google engineers that they realized that the smoothness of the steering clock must be controlled, and that the the maximal deviation in rate is a secondary concern that is best left to a parameter of the solution. As long as that window size is less than the distance between successive leap seconds, UTC[Google] is well-defined -- eg, when UTC was 2008-12-31T23:59:60 (beginning of a "positive leap second"), UTC[Google] was 2008-12-31T23:59:59. I have never seen an equally clear statement for the value of type time_t to be returned by POSIX calls of time(), even with parameters left unspecified. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] 2 meetings on UTC and the impending ITU-R RA vote
On 2011-07-11 12:43, Tony Finch wrote: Quartz clocks can be more stable than Earth rotation: see for example http://www.ieee-uffc.org/main/history.asp?file=marrison Thanks for this interesting reference! The first outstanding application of the quartz clock to astronomy was made in Germany with the installation at the Physikalisch-Technische Reichsanstalt. This was described by Scheibe and Adelsberger in 1932 and 1934, and reports of its splendid performance continued periodically. It was with this installation that it was possible for the first time to observe and measure variations in the earth's rate occurring over intervals as short as a few weeks. Previous measurements of such variations, involving studies of motion of the moon, the planets, and Jupiter's satellites, had required years to obtain comparable information which, of course, by nature, could never reveal short-term factors. Yes, quartz clocks are much better than pendulum clocks in interpolating astronomical time between observations. But they are not good enough to establish an _independent_ time scale to which astromnomical time could be referred. Their long term stability is not good enough for that purpose (apparently even today, see eg McCarthy, Seidelmann: "TIME -- From Earth Rotation to Atomic Physics", page 151). I thought this innovation was one of the reasons for moving to ephemeris time as the basis for calibrating clocks, instead of relying on transit instruments. Ephemeris time was introduced because the dynamical ephemeris (of the Moon mostly) at the time showed that its time coordinate differed from universal time, and this could no longer be ascribed to defects in the theory. Quartz clocks have been instrumental (since around 1937) in showing the variations of the length of day, which are the cause of the difference between UT and ET. And since the length of the second of UT in the early 19th century is not an easily reproducible definition, the second was redefined in 1954 using the rate of ET at 1900.0 (which is not so easy to reproduce either). But ephemeris time was deduced from astronomical observations of the Moon, not from quartz clocks. (Even today, astrometric observations of inertial time are not superfluous -- they reveal a slight difference between the rates d(TT) of TT and d(TAI) of TAI.) Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] 2 meetings on UTC and the impending ITU-R RA vote
On 2011-07-10 01:04, Steve Allen announced the meeting: In London UK on 2011-11-03/04 http://royalsociety.org/events/UTC-for-21st-century/ In that announcement, I find the following quote to be grossly misleading: "After the short reign of ephemeris time as the world’s reference time scale from 1954 until 1967, Coordinated Universal Time (UTC), which is TAI synchronized to the rotation of the Earth by means of leap seconds, appeared at the time as the best compromise for satisfying the equests of all users and was adopted in 1972." Ephemeris time (ET) _never_ has been the "world’s reference time scale" -- since 1925, and until now, the "world’s reference time scale" always has been some form of universal time (UT). What actually has changed in both 1954 and in 1967 is the definition of the second -- of course without changing its length as far as could be ascertained at the time, and hence without any change to the "world's reference time scale". In fact, from 1954 to 1967, ET has been some 31 s to 37 s fast on UT, so that switching civil time to ET never was a realistic option. There is quite a difference between changing a time scale and changing the definition of a time unit, and I would expect the people who decide on the future of the UTC time scale# not to confuse these two. Another thing that changed significantly from 1955 until 1959 is the method of _realization_ of the "world's reference time scale" (the time scale that is widely disseminated and that is used as the time argument in the celestial and nautical almanacs, I assume). Before the advent of atomic time keeping, clocks were less stable than astronomical observations of Earth orientation, so that clock rates were adjusted post factum to fit the astronomical observations at each site. With atomic clocks, however, the clock rates could be estimated ante factum, but phase offsets were an are still needed to correct for estimation errors. Moreover, since 1961, estimated clock rates and phase offsets have been coordinated across the world and across all time observatories, so that disseminated time scales of different observatories can be compared reliably. Perhaps, this change of realization was meant -- but it happened long before 1967 and cannot be called a "reign of ephemeris time" in any sense. This is all common knowledge, and can for example be looked up in the excellent book by Dennis D McCarthy and P Kenneth Seidelmann: "TIME -- From Earth Rotation to Atomic Physics". I find it quite disconcerting that some of the people who decide on the future of UTC apparently are not even aware of these basic facts or, at least, are unable to express them unambiguously in plain English. After all, these people are the representatives of the public at large concerning the choice of the civil time scale for the next generation. Regardless of how they came into that position, they should at least be knowledgable in the field in which they are about to take far-reaching decisions. Michael Deckers. NB. Having studied several papers of Dr Felicitas Arias, I am sure that my critique does not apply to her position and her writings. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] IERS colloquium on redefinition of UTC
..and chaired by list members is announced in http://data.iers.org/products/2/14839/orig/message_191.txt (Sorry iff this has already been posted here.) Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Get off my lawn!
Many thanks to Steve Allen who informed us on 2011-06-17 about three revealing documents: http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-38_CGPM-ITU-resp.pdf http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-37_UTC_possible_redefinition.pdf http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf I am not so much surprised that politics seem to play a big role in the lofty circles of the CCTF, the BIPM consultative committee on time and frequency. What I find really embarrassing is in the third of the sources CCTF/09-27. In it, the CCTF state that "UT1 is computed from the raw observed universal time UT0 by correcting it for the effect of polar motion on the longitude of the observing site." This hasn't even been fully correct during the times when UT1 was observed with zenith telescopes (before about 1980). It is incorrect today -- all the seven parameters of Earth orientation are of course determined together, and UT0 is no longer needed nor used by anybody. Do we really want those people decide on the future of UTC when they do not even know how UT1 is currently determined? And this document bears the logo of the BIPM and is signed by its director! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Some definitions --> practically stated
On 2011-03-09 15:36, Warner Losh asked: Out of curiosity, does anybody know of a system that chose to implement time_t as a float/double? The MacOS X system call CFAbsoluteTimeGetCurrent() returns an IEEE 64 bit float. Also, PostgreSQL can (still ?) use doubles for TIMESTAMP values as an option. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] one second tolerance
On 2011-02-10 20:42, Poul-Henning Kamp wrote about the Danish summer time law: Yes, one interesting detail here is the use of the word "klokketiden" which literally means "(Church-)Bell-Time", but which most people would understand as "clock-time" This word first appears in 1946 in the first law to introduce DST in Denmark, and _presumably_, but we cannot know for sure, this was meant to distinguish "clock time" from "solar time": http://ordnet.dk/ods/ordbog?query=klokketid Very interesting indeed! "klokketiden" also shows up in web sites of Greenland and Norway (bokmål). I do not know enough Danish -- could it have a function similar to the (US) English wall clock time? He continued about the use of suffixes 'A' and 'B' to distinguish between the "repeated" datetimes that occur when a civil time scale is set back from summer time to winter time: I have only ever seen it once, and that was my own doing: When we ran into this, We tried to see if we could fit the 'A/B' designator on the receipt printed by the automatic gas-pumps without using another line of text. We couldn't and since we could not have a special print format during that one hour a day, compliance would have used 138km more paper per year. Which evidently wasn't worth it. I've heard objections against the notation on the grounds that letter suffixes like A and B are used in the military, where they denote fixed time zones (Alpha for UTC + 1 h, Bravo for UTC + 2 h, ...). Thanks. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] one second tolerance
On 2011-02-09, Poul-Henning Kamp wrote: In Denmark the law used to say that you have to suffix the timestamp with 'A' and 'B' during these two hours. Interesting. That notation still seems to be legal, see [http://www.retsinformation.dk/Forms/R0710.aspx?id=22064]. In Germany, the law allows for a similar notation but does not require it. The notation is both more general (a separate token is applied before and after the discontinuity, this works not just at the end of a whole hour or minute), and potentially less confusing than the notation of ITU-R 460 with second field values >= 60. However, I have never seen that notation being applied in practice in Germany, not even by the PTB. Has it ever been used on a perceivable level in Denmark? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] What's the point?
On 2011-02-08 16:29, Poul-Henning Kamp wrote, answering Rob Seaman: > Civil timekeeping is a worldwide system. No it is not. UTC is a "worldwide coorporation" or "worldwide coordination" if you will. There is no international entity which can mandate what civil time must be in any particular country, and therefore there is no other system than what emerges through voluntary coordination and cooperation. And the cooperation only happens to the extent people want to, there are no penalties for deciding on stupid timekeeping in your own country. Nobody can prevent your government or my government from defining local time as UTC + Xh 31 minutes + 41.5 seconds. In 1884, an international conference decided: That the Conference proposes the adoption of a universal day for all purposes for which it may be found convenient, and which shall not interfere with the use of local or standard time where desirable. That this universal day is to be a mean solar day; is to begin for all the world at the moment of mean midnight of the initial meridian, coinciding with the beginning of the civil day and date of that meridian; and is to be counted from zero up to twenty-four hours. That international agreement has since become, and still is, the rationale for the worldwide use of UT, UT2, and UTC as the basis for the definition of all local civil time scales, even at those strange places where the civil time scale is defined as UTC + 31 min + 41.5 s. The proposed distribution of a translate of TAI as the time scale to be distributed worldwide, and thus to be taken as the basis of all civil time scales, amounts to the abrogation of this decision of 1884. So many esoteric technical issues have been raised in the discussion about this matter that I am wondering whether the ITU-R people may still be aware of the importance of their decision: they are going to revise the agreement of 1884. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Consensus building?
On 2011-02-02 13:32, Gerard Ashton wrote: - the SI second is part of a coherent system of units and redefinition of the second would disturb the definition of most other units Right. Except of course for redefinitions that do not change the value of a unit, but only the method of its fundamental reproduction. This will doubtless happen to the second in due time, as it will happen within a few years for kg and A, probably for K, and possibly also for mol. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Consensus building?
On 2011-02-03 20:24, Warner Losh wrote about time units minutes, hours, days: In my defense I'll note that they used to be non-SI units that were recently added to SI due to their widespread use The only SI time unit is the second -- min, h, d are _not_ SI units. They were never "added to the SI", nor will they ever be. One of the principles of the SI system is to have one and only one unit per dimension, or at least, per quantity. And the BIPM try very hard, even in the presence of °C and K, Hz and Bq and rad/s, Sv and Gy. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 51, Issue 7
On 2011-02-02, Mark Calabretta quoted and Warner Losh wrote: http://books.google.com.au/books?id=PJLlWzMBKjkC&pg=PA183 Looks like the page limit has been reached... :( I'll start a new google search. thanks! The reference by Vallado and McClain is a bit dated anyway -- it appears to be based on the 1992 Supplement. A more current and freely available description is in Kaplan's excellent summary at [http://www.usno.navy.mil/USNO/astronomical-applications /publications/Circular_179.pd]. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Consensus building?
On 2011-02-03 14:00, Clive D.W. Feather wrote: Actually, Stephen is right and you're wrong. The BIPM defines an SI minute, hour, and day in exactly this form. See table 6, page 32, of: http://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf It may seem picky, but nevertheless: the BIPM does not define an "SI minute" in the SI brochure, nor anywhere else. It defines the time units minute, hour, and day in terms of SI units, and allows their use together with SI units. Thus d, h, min are are well-defined units, but they are not SI units. Calling them "SI-minutes" etc is misleading, in my opinion. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Meeting with Wayne Whyte
On 2011-02-01 11:35, Poul-Henning Kamp wrote: Thanks to leap-seconds we do not know how long (certain) minutes are, until Daniel tells us. Daniel Gambis does not define certain time units, he just communicates the difference TAI - UTC as soon as it becomes known for another six months. "UTC is unpredictable" is the core of the problem, and a problem that must be solved, either by extending the predictability horizon from six months to at least 10 years, or by making UTC predictable. What currently is unpredictable far into the future is the difference TAI - UTC. Now the difference TAI - TT is also unpredictable -- but is that a reason to say that either TAI or TT is unpredictable, or to redefine one of them? As far as the civil uses of time scales are concerned, it is actually UTC rather than TAI that is currently more "predictable": I can predict with great certainty that I shall attend a group meeting when UTC will be 2012-01-30 + 09 h, but TAI at that instant is currently only known with an uncertainty of 1 s. How could the unpredictable difference TAI - UTC be a problem if everybody (including every computer) just kept UTC? Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java JSR-310 TAIInstant class
On 2011-01-29 22:21, Stephen Colebourne wrote: What JSR-310 needs is a single time-scale that has a single incrementing number of fixed size units (SI seconds) with no other interpretations (such as what a day is). I believe that TAI best meets that definition today, and thus is the choice made. IMHO, a programming language should * recognize the fact that there are many time scales, none of which is better or worse than the others, and for which any given implementation may or may not provide real time clocks; * support the relationships between time scales as they occur in practice (eg, UTC -- TAI with lepa seconds (and milliseconds), UTC -- time zone times, order relation of UTC timestamps, etc). But it should not: * make unfounded assumptions on time scales (like any time scale can be reliably converted to TAI and back -- TAI exists only since 1958 but datetimes cover a much broader range); * expose any internal constructs (like auxiliary time scales). The goal should be to model reality as far as possible and desirable (eg, one might decide to ignore archeological time scales at first). Squeezing reality to a model that does not quite fit just to make things simpler is, in the long run, bad for users and designers. (This is the essential theme of this list, by the way.) I wouldn't comment on this if JAVA were not such an important language. With your UTC-SLS time scale, for example, you prohibit correct comparison of timestamps with nanosecond precision during positive leap seconds. This is the typical design inconsistency that can cause implementation errors and, ulitmately, viruses. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Java: ThreeTen/JSR-310
On 2011-01-28 18:34, Gerard Ashton asked: Windows and Unix have general reputations of not doing it right; does anyone know of a hardware/operating system combination that handles leap seconds correctly? If so, does it have a defined approach to providing a quasi-UTC that hides leap seconds to applications that wish to live in blissful ignorance? No, I do not know where it is done "correctly" -- I just know some programming languages where datetimes and time scales are modelled in other ways than in the JSR-310 proposal. Let me just mention two. Take ADA95, for example. The language accepts the existence of various independent time scales, that is, physical quantities that all take their values in the same space of datetimes. That space provides the operations of an affine space over the one-dimensional vector space of times, with units s, min, h, d, etc. Datetimes values can be denoted using calendars or with affine units such as Julian dates or Besselina epochs. Whether values of one time scale can be converted (in whatever sense) to values of another time scale is not imposed by the interface. Some time scales can be converted exactly (eg, TCG to TT), some exactly only for past epochs (eg, UTC and TAI), some only approximately, even for the past (eg, TT to TAI). ADA95 also recognizes the fact that it is sometimes needed to add additional information to a datetime value: viz, the information that the datetime value occurs twice in a non-monotone time scale. This is needed to order such amended datetime values in the case of leap seconds, and in the case of civil time scales while they switch from summer time to winter time. Other additional operations on these values comprise better conversions to other time scales, eg, unambiguous conversion from UTC to TAI, or from civil time to UTC with the help of a zic file. SQL provides datetime values with an additional offset so that they comprise both a local time scale and a UTC value. This is another form of amended datetime values that is important in applications. It can also model a UTC time stamp with known offset to TAI. This amendment is independent of the previous one, so that I would expect a complete support to provide datetime types with both amendments, too. I have left out all the gory details and I hope this comment is still not too abstract. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Looking-glass, through
On 2011-01-14 16:26, Warner Losh wrote: The BIPM collects time and frequency data for the different clocks, measured against each other. Each clock then has an error in frequency and time computed. These clocks are then weighted based on assigned values (based on the time scientists best guest about how good the clocks are). This value goes in to producing what's called a 'paper clock' which is a historical look at what the best guess at the actual time for each of these measurements. Based on that, you can know how close your clocks are running, and can steer them, if you wish. The actual process as used by the BIPM (since 1977) is a bit more complex. The weighted mean of atomic clock readings results in an intermediate time scale called EAL (échelle atomique libre); in a second step, TAI is determined as an affine function of EAL so as to approximate the frequencies of the best atomic clocks. See for examle Dennis D McCarthy, P Kenneth Seidelmann: "Time -- From Earth Rotation to Atomic Physics". Wiley-VCH. 2009. pages 201..216. The process was even more complex while the rate of TAI was intentionally increased during 1995..1998. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Accuracy and Precision
On 2011-01-12 17:33, Finkleman, Dave wrote: These terms [accuracy and precision] have appeared in recent exchanges. Keeping the distinction clear is one of my continuing quests. Perhaps I have it wrong, too. I am sure that someone will let me know. Accuracy is how well a measurement compares to a standard. If my one meter measuring stick is not one meter long, every measurement I make with it will be inaccurate. Precision is the variation among measurements. Even if the measuring stick is absolutely one meter long, every time I make a measurement, I may misplace it a bit. Each realization of the same measurement will be different. Good! These definitions are in fact close to the ones in VIM (International vocabulary of metrology, by the Joint Committee for Guides in Metrology, headed by the BIPM and online at [www.bipm.org/en/publications/guides/vim.html]). UTC provides precise time intervals for most practical purposes. However, it is inaccurate as the difference between UTC and time scales based on Earth rotation grows. I know precisely at the end of 86,400 SI seconds, that my perception of where I am in space is wrong. I do not understand: accuracy applies to any measurement, precision applies to repeated measurements of a single measurand. If UTC is considered as the (combined) result of measurements (to which these notions would be applicable) then what is the measurand? Shouldn't UTC be considered as a physical quantity that can be measured in diverse ways (NTP, GPS, UTC(k),..), each method having its own accuracy and precision? Or do you allude to the fact that UTC has a non-zero definitional uncertainty (as does TAI) -- which a fortiori is a bound for the accuracy of any measurement of UTC? Finally, if I want to know where I am after 86 400 s, I would use an inertial coordinate system for time and space -- the "rotating geoid" with UTC or TAI is not (part of) one of those. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Who do we develop standards for?
On 2011-01-01 17:50, Finkleman, Dave wrote: I have learned in my ISO work that we develop standards for those to whom the issue matters -- not for those who are unaffected or have no stake. In our AIAA paper we enumerate the criteria for a standard. Working groups are appointed to develop specific standards. Each member must be a recognized expert. Each must have a material stake in the outcome. Membership must be balanced among industry, academia/research, and government at least to the extent that no single group can dominate. For the issuance of ISO standards, only national standardization committees can be contributing P members, not persons. While I have contributed to ISO IEC JTC1 SC32 via the German standards organization (over ten years), the committe was always dominated by participants from industry. I am not aware of any ISO rule to the contrary. IMHO, the most effective control of ISO standards is the public review and comment period (usually of 3 months) to be held before an "FDIS" can become an ISO standard. Every comment raised within that period has to be considered and resolved by the working group. This prevents contentious standards being adopted without serious discussion and without a big majority in favor (it does not prevent useless standards, though). The operating procedures of ITU (as well as those of many other consortia like IEEE, MPEG,...) do not seem to require a public review before a standard is adopted. The only way to influence the content of a standard is the participation in the standardization work -- which is laborious and expensive, and therefore limited to the immediate stakeholders. The standard defining UTC should be up for public review before it is imposed on the world because nobody can choose not to use it. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Ghosts of Leap-seconds past and future
On 2010-12-28 18:33, Tony Finch asked: Do practical systems get DUT1 from time broadcasts > or from files downloaded from the Internet? I do not know -- but this is one of the questions I would expect to be answered when it is decided to which degree of precision UT is made available with UTC disseminations. With the current proposal for revision of ITU-R TF.460, UTC time signals are no longer intended to provide access to UT, so for the proposal, the question is moot. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Ghosts of Leap-seconds past and future
On 2010-12-28 12:56, Richard B. Langley wrote: I have been asked to remind list members of the presentation by Ron Beard, the chairman of ITU-R Working Party 7A, at ION GNSS 2010. The PowerPoint slides can be downloaded from here: <http://www.navcen.uscg.gov/pdf/cgsicMeetings/50/%5B16%5DITU_Status_UTC_Revision_CGSIC_50th.pdf>. Here are the conclusions, summary, and actions from the presentation: ... Thanks. What surprises me in that summary is not what it says but what it does not mention. Two examples: [a] While the summary mentions the "questions" circulated by the Working Group, it does not state which changes really are intended -- those of the US proposal at [http://www.navcen.uscg.gov/pdf/cgsicMeetings /50/%5B16%5DITU_Status_UTC_Revision_CGSIC_50th.pdf], I assume. [b] This proposal does not only change technicalities like the maximal difference |UTC - UT|, but it changes several other things (more important things, in my opinion). For instance, it removes the immediate availability of UT from the goals of UTC dissemination. Was anybody asked about this? Do most of the experts agree? The US proposal contains provisions that only take effect in several hundreds of years. In view of the current revision cycle of ITU recommendations, this is absurd. I take this as an indication that the US proposal has not even been subject to a formal review by the ITU working group. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Leap seconds, precision time, and technical progress
On 2010-12-26 17:33, Dave Finkleman wrote: Technology advances to exploit our ability to realize and measure time precisely increases. Use of spectrum with frequency, time, and code division multiplexing is an example. I realize that the time scale of such applications need not have a uniform epoch in the distant past or be tied to astronomical phenomena. Perhaps you can think of better examples that do. Therefore, it is broadly important that precise time accrual be synchronized and coordinated. Astronomical phenomena are the most fundamental vehicles for synchronization. They belong to no one. No one can control them. I think this is a good argument _against_ the current definition of UTC. "Precise time accrual" is achieved today by integrating stable clock frequencies, not by astronomical observations. The astronomical phenomenon that is used for determining the phase of UTC is the rotation of the Earth, and this is no longer one of the "fundamental vehicles" for synchronization because it is (currently) neither constant nor predictable to a sufficient degree. The quest for the redefinition of UTC is based right on this incoherence: the rate of UTC is a "fundamental vehicle for synchronization" and is used as such in innumerable applications, while the phase is erratic. The suspicion is that a less erratic phase would not hurt as many applications as the incoherence could. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 48, Issue 13
On 2010-12-16 17:57, Dave Finkleman opined: I learn something with every exchange. Thanks. This is what is in ISO 31-1, which is now ISO 8-3 "time, time interval durationt second s [a lot of lines of Physics 101 elided] Well, I assume you knew these facts long before ISO 31 became deprecated. Standards often have to state the obvious, just in case. If you want beefy stuff, look into ITU-R TF.1010 -- which also is 13 years old but regretfully not well-known. Anyway, in my humble opinion, the real issue, as far as the possible redefinition of UTC is concerned, is not the depth of one's insight into the physics of spacetime -- the clarification needed concerns the concepts (or the terminology, if you prefer), and the design goals, as Rob Seaman is continually pointing out with much more eloquence than I can convey in my scribblings. To put it in provocative terms: we (eg, the people on this list) do not agree on what a world-wide civil time scale should accomplish. I think we do not even agree on what a quantifiable time scale really is. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] LEAPSECS Digest, Vol 48, Issue 12
On 2010-12-15 17:47, Finkleman, Dave wrote: ISO 8601 is a problem. So far I have not heard anything from ISO TC12, which is responsible. But I am diligent. I will extract something from them. Their treatment of time is "deficient" and inconsistent. I don't know how this was coordinated either. Most of their treatment of time is just vetting almost every possible way of expressing the digits. I do not understand why ISO 8601 is a problem. If you mean their explanations of "time scale", "time point", "time axis" etc -- well, these are indeed arcane, but they are just taken from IEC 60 050. (Nowadays, ISO/IEC 80 000 is the international standard for terminology regarding physical quantites. And the IAU regulate their own astronomical time scales, of course.) The scope of ISO 8601 covers the numerical notation of datetimes, but not their definition. And for that goal, ISO 8601 has been quite successful, in my opinion: + it defines the Gregorian calendar; + it defines week dates which are useful in business applications (also obsoleting quests for perpetual calendars); + its notations are applicable over all ranges, past and future, for any timescale, and for fairly arbitrary resolutions (just resolutions > 1 year are not (yet) possible); + it has been adopted widely in the computer arena. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] A leap second proposal to consider -- LSEM
On 2010-11-04 21:46, Zefram wrote: There is a recent near-renaming that shows the way: the modern form of Sidereal Time is known as Earth Rotation Angle. This name is accurate in some important ways: it's specific to Earth, and it's not time at all but an angular measure. To be precise, Earth Rotation Angle exists _in addition_ to a modern form of Greenwich mean sidereal time, whose definition uses both ERA and TT. See for example p 16 of [http://www.usno.navy.mil/USNO/astronomical-applications /publications/Circular_179.pdf]. The new name denotes a new concept, the old concept has retained its name. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] A leap second proposal to consider -- LSEM
On 2010-11-03 23:31, Steve Allen remarked: I see the point of "mean solar time" not as "how accurately does the expression represent the sun over the earth?" but as "does the expression even try to represent the sun over the earth?". I think that the discussions and intentions surrounding the current draft revision of TF.460 indicate that it does not try. Yes, you are of course right. My point is that even UT1 does not try. Sidereal time is no longer an affine function of UT1. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Back to Basics
On 2010-11-03 18:25, Steve Allen wrote: Remember that the standing CGPM resolution says that UTC is mean solar time. http://www1.bipm.org/jsp/en/ViewCGPMResolution.jsp?CGPM=15&RES=5 No. It says "approximation to .. mean solar time". That this is meant is grammatically unambiguous in the French text: "..que sa diffusion fournit aux utilisateurs à la fois des fréquences étalons, le Temps atomique international et une approximation du Temps universel (ou si l'on préfère, du temps solaire moyen),.." ^^ approximation du.. And certainly, UTC _is_ an approximation of UT1. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] A leap second proposal to consider -- LSEM
On 2010-11-03 18:43, Poul-Henning Kamp observed on a remark by Rob Seaman: > "Universal Time" *means* "mean solar time". It probably did in the 1800's, in these days of Lego-toys on Mars, most people I have talked to, find it utterly strange that a timescale with "universal" in it, depends on one particular lump of rotating rock. Since 2003, UT1 has no connection with the Sun -- it measures Earth rotation independent of the revolution of the Earth around the Sun (except for geodesic precession, sigh). So "mean solar time" may well be considered a misnomer for UT1. Since sidereal time is still well-defined (based on both UT1 and TT), any definition of a mean sun could resurrect mean solar time in the original sense, if desired. For the time being, it would not deviate appreciably from UT1 (because that's how UT1 was redefined). Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] An example
On 2010-11-02 18:55, Poul-Henning Kamp wrote, first quoting Steve Allen: > The existing international agreement for the meaning > of "day" is "mean solar day". You mean "one of the existing..." ? The astronomical meaning of the word day may indeed be what you say, but the equally internationally agreed standard for computer operating systems define a day as 86400 SI seconds. The question is which one ITU-R adopts. Isn't a day always exactly 86400 s, in whatever time scale you are considering? If you consider UT, you get mean solar days, if you consider TCB you get a day of coordinate time for the solar system, and if you consider UTC you either get the same as you would get with TAI, or 1 s more of TAI. Upon comparison, these intervals of days are different (and the difference may even depend on the method of comparison), but the time scales nonetheless use the same units of days, hours, minutes, seconds, hours. It is the very basis of relativity that two time scales both measured in SI seconds do not necessarily give the same intervals of days everywhere. Other time scales with the same property (which, accordingly, they must have!) add no further complication, in my opinion. For height above the geoid (altitude) we have a similar situation: there are several notions of geodesic height, and their height diffenrences do not agree, but all can be expressed in the same unit of SI meters (or feet). Anyway, thanks for the illuminating exchange of ideas about the fate of UTC! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] New time scale name
On 2010-08-11T17:14Z, Tony Finch wrote: On Wed, 11 Aug 2010, ashtongj wrote: > If dropping leap seconds is ultimately approved, we will need at least two > names for the new time scale. Alternatively, name the successor to UTC "TI" and if you want proleptic TI call it "proleptic TI". I fear that the matter is less simple. The proposal keeps the name UTC for the newly defined timescale. (And unfortunately, there is precedent with essential changes in definitions of well established time scales: GMT.) So that, absurdly, those people who continue to use UTC in the established sense could not keep the well-established name for it -- they would have to find a new name to avoid ambiguity (eg, UTL for UT with leap seconds). Everybody else does not rely on the precise definition; they can (and should) continue to use the name UTC without even knowing that it had changed definitions. Which is, I have to admit it, the charm of the proposal: those who need to know the exact definition of UTC old and new would have to change the name for the continuation of UTC in the old sense, along with quite a bit of their other software. But the rest of us (the overwhelming majority) need not care. Would the ITU-R care to give a name to the time scale that continues the old definition of UTC? I guess they wouldn't -- this is probably not seen as a technical question, even though systematic terminology is a technically important matter, in my opinion. So this might be the real terminological challenge: we need a new name for the time scale defined in the way that UTC currently is. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ITU-R SG7 to consider UTC on October 4
On 2010-08-09 22:17, Poul-Henning Kamp wrote: In message<4c607952.2090...@yahoo.com>, Michael Deckers writes: > I am confused: there is no time scale specified in the Danish law > quoted. Do you mean that the reference in the footnote is supposed > to include the Danish text of a European Directive into Danish law, > without even explicitly quoting it? Yes. This I find very hard to believe. I do not think this would be possible in English or German law: if prior written law was superseded it had to be revoked or changed explicitly, paragraph by paragraph. I have personally helped installed TCP/IP on all computers in the European Parliament in an earlier job. I met a LOT of the translators back then. I can tell you that a detail like the proper name for a timescale does not even register on their radar. So yes, I will argue that the directive specifies that all countries in EU change summertime at the same exact instant and that this is defined on the UTC timescale, which people call all sorts of different crap for historical, and in the case of GMT, hysterical, reasons. I can absolutely guarantee you, that if your argument is that the directive does _not_ say they should switch the same instant, you will have absolutely no traction in the EU-mindset, which is hell-bent on unifying the countries to a degree you can not even begin to fathom. I can see what the European Directive says, regardless of the mindset of European bureaucrats. The Directive is not clear about the time scale, and not just because of your description I think that if these bureaucrats really had intended to prescribe UTC then they would have succeeded in doing so. They didn't. As it stands, the Directive says the time of switches to and from summer time is 01 o'clock GMT or UT or WT or UTC, or whatever the time base is. As you have remarked above, the translation of the Directive is sloppy about that time scale (which is not too bad because a European Directive is not by itself law anywhere in the world). For instance, in German, the EU Directive says "world time", but the base for legal time in Germany is UTC, and in Austria it is GMT. Both countries have their summer time law adjusted to the Directive, but without incorporating or referencing the text of the Directive, and without changing their base for legal time. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] ITU-R SG7 to consider UTC on October 4
On 2010-08-09 11:04, Poul-Henning Kamp wrote:
In message<20100809104622.gc32...@davros.org>, "Clive D.W. Feather" writes:
> . You said that the EU directive redefines the
> basis of legal time in Denmark (this was in the context of UT v UTC).
It does.
They ratified the EU directive in a Danish law, most recently
(http://retsinformation.w0.dk/print.aspx?id=22064) which defines
that DST ("sommertid") starts 02:00 (local time) (etc).
I am confused: there is no time scale specified in the Danish law
quoted. Do you mean that the reference in the footnote is supposed
to include the Danish text of a European Directive into Danish law,
without even explicitly quoting it?
So now we have:
A) The law about "determination of the time" says solar time at -15long.
B) EU directive says DST starts at 01:00Z
No. The text of European Directive 2000/84/EC of 2001-01-19 is
issued by the EU in 22 languages, all with equal standing.
For the time scale determining the beginning and end of
summer time, these translations refer to:
-- Greenwich time in 4 cases (EL, ET, HU, LV)
-- Greenwich time with GMT in parentheses in 1 case (SV)
-- Greenwich mean time in 5 cases (EN, FI, LT, MT, SK)
-- Universal time in 5 cases (ES, FR, IT, PT, RO),
-- Universal time with GMT in parentheses in 1 case (PL),
-- World time (a term for UT according to the IAU) in 2 cases
(DE, NL),
-- World time with GMT in parentheses in 1 case (CS),
-- World time with UTC in parentheses in 1 case (DA), and
-- Universal coordinated time in just one case (SL).
(Thanks to Steve Allen who first did this comparison.)
In my opinion, this shows that the Directive does not
intend to prescribe the time scale. Or do you
think that it was the idea that the Danes and Slovenes
should follow UTC while the British follow GMT? Then certainly
the Welsh, Gaelic, Catalan, Basque,.. people would want to have
their own versions!
Michael Deckers.
___
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Terminology question
On 2010-03-10 22:42, Steve Allen wrote: In the lingo of the atomic horologists I would say "the relationship between UTC(TAI) and TAI is simple." Here UTC(TAI) means "the version of UTC constructed in arrears by using the contents of Circular T". But IERS Bulletin C would suffice for the relationship between UTC and TAI, and that is available a bit earlier. The relationship between any other realization of UTC and TAI is not simple. Yes, modulo IERS Bulletin C it is as complicated as the relationship of the realization of UTC to UTC proper. > If I understand you correctly: my computer gives me UTC(my_computer) > and I can convert that easily to TAI(my_computer) In the lingo of the atomic horologists there can be only one TAI. There is no published entity such as TAI(anything else), and the transcripts of discussions indicate that people get chafed when anyone uses such a lingo. Oops, you are of course right. I should have written TA(my_computer). > I do not understand how the formal definition of UTC limits its > precision to 1 ms. UTC can be determined with the same > uncertainty as TAI. Yes, but only as of next month, when the next Circular T is published. That is unsuitable for an operational time scale which is needed now. I see. Nevertheless it may be useful to apply the conversion from UTC to TAI also to approximate UTC values: the resulting approximate TAI values are closer to a proper time scale, and this may be desired when computing the length of time intervals. I believe it is this distinction that prompted the creation of GPS time and BeiDou system time as opposed to calling those system times by any sort of name related to TAI. Also notice carefully that the ICD which defines GPS time indicates that it is based on UTC(USNO), not on TAI. I suspect that in the statutory language of its mission there is no requirement for the USNO to deal with TAI, only UTC. It is only the compliance with the treaties which brings them to contribute to TAI. Yes, GPS time is steered to UTC(USNO) (modulo some leap seconds). The construction of GPS time out of the participating clocks sounds even more complex than the construction of TAI because GPS time is also used as the time coordinate of an ephemeris. And the relationship to UTC(USNO) is available in real time with at most 90 ns error! Thanks for the comments! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Terminology question
On 2010-03-10 17:54, Steve Allen wrote: On Wed 2010-03-10T16:05:28 +, Michael Deckers hath writ: > On 2010-03-09 17:34, Zefram wrote: > > Apparently not. I'm inclined to use the phrase "faux linear time". > > These timescales are really encodings of UTC-wise broken-down time, but > > they sufficiently resembles a linear timescale that it's commonly mistaken > > for one. I think it's worth reminding people clearly of the reality. > > Perhaps "piecewise linear" may also be appropriate -- it is a > common term in math. TAI - UTC (after 1972) may then be called > a "step function", which is a "piecewise constant" function. Except that to say that any available form of UTC is linear is to invalidate its use as a precision time scale. "piecewise linear" is not "linear" -- it is a mathematical way to say "faux linear". More precisely, it can express the fact that between any two successive leap second events (and also after the last such event), a POSIX time scale, and also UTC looks like a linear time scale. (Actually, the term would even apply to UTC before 1972.) Read BIPM's Circular T. http://www.bipm.org/jsp/en/TimeFtp.jsp?TypePub=scale Follow the link to BIPM's TT(BIPM09) Plot the numbers. It's not linear. You are right in that "linear" requires a qualification, as in "linear function of ..". And so does "piecewise linear": UTC would be a piecewise linear function of TAI, and of TT(TAI), but not of TT, nor of TT(BIPM), TCB, TDB, UT1,... Some nice graphs with d(TAI - TT(BIPM)) are in [www.bipm.org/utils/common/documents/tai_2004/TAI-GP-4.pdf]. All precision time scales must employ empirical lookup tables. Leap seconds are just one form of lookup table, and the total number of table entries for UTC is smaller than for the other scales. Yes, the relationship between UTC and TAI is simple. I also suggest "piecewise linear" as a description of the relationship: there are intervals of TAI values on which UTC is linear in TAI, and arguably such intervals cover the range of all TAI values (except possibly during positive leap seconds). If the question simply wants "generic" UTC, then from the formal definition we can only expect a precision of 1 millisecond. In that case I could say "linear within the 1 ms precision of the formal specification of UTC as defined by ITU-R TF.460", but according to that as soon as a computer system clock deviates by more than 1 ms it can no longer claim to be UTC. In that case what is it? If I understand you correctly: my computer gives me UTC(my_computer) and I can convert that easily to TAI(my_computer), with the usual lookup table. The error and the uncertainty with respect to UTC and TAI are the same. I did not want to suggest that UTC(my_computer) was a linear function of UTC. It certainly isn't! I do not understand how the formal definition of UTC limits its precision to 1 ms. UTC can be determined with the same uncertainty as TAI. This is the vocabulary issue which triggers me to answer "mu", for many of the questions seem to want an answer which is far simpler than required to describe (or even in denial of) reality. Hai, you are right, an easy term should not cover up a complex relationship. POSIX systems use different ways to represent UTC values around a positive leap second in a time_t value, and the details are not so easy to find out. In the few cases where I (thought I) understood the scheme, "piecewise linear function" of TAI was a valid description. Also, the time scale UTS proposed by Markus Kuhn for use in information and communication systems is a "piecewise linear" function of TAI in the exact mathematical sense (see [http://www.cl.cam.ac.uk/~mgk25/uts.txt]). Thank you for your detailed comments! Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] Terminology question
On 2010-03-09 17:34, Zefram wrote: Tony Finch wrote: > Is there a generic term for timescales like POSIX time_t and NTP that > count seconds (or some other interval) since an epoch without taking > leap seconds into account? Apparently not. I'm inclined to use the phrase "faux linear time". These timescales are really encodings of UTC-wise broken-down time, but they sufficiently resembles a linear timescale that it's commonly mistaken for one. I think it's worth reminding people clearly of the reality. Perhaps "piecewise linear" may also be appropriate -- it is a common term in math. TAI - UTC (after 1972) may then be called a "step function", which is a "piecewise constant" function. Michael Deckers. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
