Re: Fixing POSIX time
Neal McBurnett said: >> UT1:Flamsteads birthday ? > Cute. 1646-08-19 O.S. or N.S.? At least it wasn't January, which would have added a third option. -- Clive D.W. Feather | Work: <[EMAIL PROTECTED]> | Tel:+44 20 8495 6138 Internet Expert | Home: <[EMAIL PROTECTED]> | Fax:+44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc||
Re: McCarthy point (was: Fixing POSIX time)
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >All I wanted to say is that for a good choice of epoch, it would be nice >if we agreed on it not only to within a few seconds (the leap-second >problem), but also to within a few milli- or microseconds (the SI/TAI >second problem). The latter seems much easier to do for 2000 than for >1972 or even 1958. In applications such as observing planetary motion >over many years, the difference matters. Good point. Presumably, the epoch will be defined relative to TAI or UTC to get maximum precision, so the limiting factor will probably be measuring (or having had measured) UT1 with maximum precision at the epoch. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Fixing POSIX time
On Thu 2006-01-19T19:00:27 +, Markus Kuhn hath writ: > Please remember that the TAI second differed noticeably from the SI > second until about 1998, because black-body radiation shift was not > taken into account in the definition of TAI before then. Also caesium > fountains have improved quite a lot shortly before 2000. True, but not really relevant. What is important for society at large is to have a time scale upon which we can all agree, and to have it available in as near to real time as possible. The fact that there have been deficiencies in the rate of TAI is only relevant to radio observatories observing pulsars and comparing those pulse timings with their own atomic clocks. In that sense there will always be a need for retrospective revision of the true meaning of the time scale which was conventionally available. If you want to have a time scale which extends far into the past, you only have a choice of UT and TT. UT is that which people knew from looking at the shadow of sticks in the ground. TT is that which historians and astronomers can deduce from records of eclipses. Starting with the IMC in 1884, UT was the time scale upon which everyone could agree (although it did not achieve agreement on that name until half a century later). Starting with the almanacs in 1901, Newcomb's expression for UT was the one on which everyone could agree. Within a few years of that, radio broadcasts became the best way to disseminate the agreeable time. As such, it became admissable to have only one entity which could be called the agreeable time. As the BIH intercompared radio broadcasts it became evident that different sources of UT disagreed because of factors both constant and variable. Thus in 1955 came the agreement to name UT0, UT1, and UT2 and to use the most uniform one as the basis of civil time. But agreement only existed ex post facto (by at least months) in the publications of the BIH. At the same time came the cesium resonator which quickly proved that it was a better way to achieve agreement on what time it was. Adding in the transistor and telecom revolutions made intercomparisons much easier, and so for technical purposes the BIH's TAI became a time upon which everyone could agree. Handing the control of UTC over to BIH let them resolve the conventional longitude problem and finally coordinate agreement at the sub-millisecond level. But the manner in which TAI is agreeable is as much political as technical, for it is maintained by a club of those who pay their dues to the BIPM and follow the BIPM rules by buying the right equipment. The question that the ITU-R is asking is what is the character of the one agreeable time which will be broadcast. That is undeniably an important concept for navigation and commerce, but it is based on a specific notion of coordinate time. As the ability increases to notice that my proper time progresses at a different rate than your proper time, it becomes possible to question whether it is relevant to admit that different applications may want to agree on different kinds of time. No matter whether leap seconds persist or cease, the nature of the agreeable time scale which is most conventionally available is going to change. The best that a computer representation can do is to be flexible enough to admit as much in the footnotes of its documentation. Aside from that it seems important not to over-specify the interpretation of the underlying time scale. To that end, examine GPS itself. The only thing its time scale acknowledges is week number and second-of-week. The signal itself does not presume anything about the conventional calendar scheme to which that time will be converted, not even to the point of pre-supposing the Gregorian calendar. Yes, there is a field for counting leap seconds, so the signal does acknowledge that the earth rotates and that people are interested in knowing how far it has rotated. Until this point in history, that has been fundamental in the notion of what we mean by the agreeable time. -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
McCarthy point (was: Fixing POSIX time)
"M. Warner Losh" wrote on 2006-01-19 19:35 UTC: > : Therefore, if people ask me for my favourite epoch for a new time scale, > : then it is > : > : 2000-03-01 00:00:00 (preferably UTC, but I would not mind much > :if it were TAI, or even "GPS time") > : > : This epoch has the following advantages: > : > : a) It is well after TAI rubber seconds were fixed in ~1998, > : so we know the time of *that* epoch with much greater accuracy than > : any before 1998. > > TAI and UTC have ticked at the same rate since 1972. While this rate > has changed twice (by very small amounts, first by 1 part in 10^12 and > then later by 2 parts in 10^14), they have been the same. Prior to > 1972 we had both steps in time (on the order of 50ms to 100ms) as well > as TAI and UTC having different notions of the second. At which point we probably have reached another "McCarthy point" in the discussion: Dennis D. McCarthy (USNO) observed at the ITU-R Torino meeting, that "people who talk about timescale differences in the order of a few nanoseconds and people who talk about differences in the order of a few seconds usually do not understand each other". All I wanted to say is that for a good choice of epoch, it would be nice if we agreed on it not only to within a few seconds (the leap-second problem), but also to within a few milli- or microseconds (the SI/TAI second problem). The latter seems much easier to do for 2000 than for 1972 or even 1958. In applications such as observing planetary motion over many years, the difference matters. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Fixing POSIX time
In message: <[EMAIL PROTECTED]> Markus Kuhn <[EMAIL PROTECTED]> writes: : Poul-Henning Kamp wrote on 2006-01-19 17:56 UTC: : > >For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. : > : > I chose the time when TAI became constant rate so that : > all the rubber seconds are confined to negative values. : : Please remember that the TAI second differed noticeably from the SI : second until about 1998, because black-body radiation shift was not : taken into account in the definition of TAI before then. Also caesium : fountains have improved quite a lot shortly before 2000. According to the web site that I posted (http://www.ucolick.org/~sla/leapsecs/timescales.html), this feature was in both TAI and UTC. From the url: UTC on 1977-01-01 Because the rate of TAI was reduced by one part in 1012, the rate of UTC was reduced by the same amount. Therefore, before this date UTC seconds were shorter than they currently are. UTC from 1995 through 1998 In 1995 a CCTF working group determined that the length of TAI seconds was longer than the SI second because the clocks contributing to TAI were not corrected for the effects of blackbody radiation. Over the next three years the frequency of TAI was steered to reduce the length of its seconds by about 2 parts in 1014. Therefore the length of UTC seconds was also reduced. This change is evident as the final kink in the plot of TT(BIPM04). [EMAIL PROTECTED] is a frequent contributer here, and this looks like his web site. I'd be interested in a source that describes these events differently... : Therefore, if people ask me for my favourite epoch for a new time scale, : then it is : : 2000-03-01 00:00:00 (preferably UTC, but I would not mind much :if it were TAI, or even "GPS time") : : This epoch has the following advantages: : : a) It is well after TAI rubber seconds were fixed in ~1998, : so we know the time of *that* epoch with much greater accuracy than : any before 1998. TAI and UTC have ticked at the same rate since 1972. While this rate has changed twice (by very small amounts, first by 1 part in 10^12 and then later by 2 parts in 10^14), they have been the same. Prior to 1972 we had both steps in time (on the order of 50ms to 100ms) as well as TAI and UTC having different notions of the second. Warner
Re: Fixing POSIX time
On Thu 2006-01-19T09:54:51 -0700, Neal McBurnett hath writ: > For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. > (I've seen more specific references that TAI was set according to both > UT2 and UT1 - but they weren't the same then. Perhaps within known > error at the time?) As near as I can find in the literature, the intention was that all atomic time scales (I think that was three of them) would be set equal to the astronomical value of UT2 as of 1958-01-01. If I am not mistaken, the formula for UT2-UT1 at that date was provisional; the expression currently in use is distinctly different. Worse than that, in 1958 the values of UT1 used by the various different national observatories and broadcast time services did not agree. They had never agreed because each observatory used its own value for its "conventional longitude" (look for the animated discussions of that term in the annals of the IAU general conventions), many of which had been established early in the era of telegraphy, and which were inconsistent with a truly global longitude system by amounts corresponding to many milliseconds of time. It is therefore somewhat moot to argue whether the epoch of TAI was synchronized with UT1 or UT2, for those quantities themselves were not well synchronized at the same level. I also point out that the IAU has standardized on 1977-01-01 as the epoch of synchronization for its time scales because that is the date on which the largest intentional change was made in the rate of TAI. If epochs are to be specified, it is incumbent on the document to specify the full four-vector (location and time) at which synchronization is intended, whether it is intended to be a specification of angle, coordinate time, or proper time, whether there is an implied conventional coordinate transformation such as the one between TCG and TT, what other conventional coordinate systems are presumed, and to ruminate on the meaning and likely precision of the time scale if someone attempts to extrapolate it either into the future or past. (By which I do point the finger at, for example, Microsoft for producing documents which imply that UTC can be used in the year 1601. The term UTC can have no meaning before 1960, and even that predates the use of the term itself by many years. Also, don't forget the other UTC which the Soviets and Chinese were using during the 1960s. And this is not to say that the astronomers have always got it right. See the draft resolutions about discarding the original meaning of TDB which are probably going to be acted upon by the IAU in Prague this summer.) In the absence of such rigor our descendants will have to make yet more value judgements about what they think we were thinking as they attempt to disambiguate the mess we make by our lack of full foresight. -- Steve Allen <[EMAIL PROTECTED]>WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99858 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06014 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: Fixing POSIX time
Poul-Henning Kamp wrote on 2006-01-19 17:56 UTC: > >For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. > > I chose the time when TAI became constant rate so that > all the rubber seconds are confined to negative values. Please remember that the TAI second differed noticeably from the SI second until about 1998, because black-body radiation shift was not taken into account in the definition of TAI before then. Also caesium fountains have improved quite a lot shortly before 2000. Therefore, if people ask me for my favourite epoch for a new time scale, then it is 2000-03-01 00:00:00 (preferably UTC, but I would not mind much if it were TAI, or even "GPS time") This epoch has the following advantages: a) It is well after TAI rubber seconds were fixed in ~1998, so we know the time of *that* epoch with much greater accuracy than any before 1998. b) It is a date that very slightly simplifies calendrical calculation, because it is located at the end of a leap day and at the end of a Gregorian mod 400 years cycle. (Otherwise, you would have to shift to that date each time to convert scalar <-> -MM-DD notation.) c) It is a date sufficiently recent, such that implementors will be forced to properly test their handling of pre-epoch arithmetic, something easily neglected in practice with epochs before 1980. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: Fixing POSIX time
In message <[EMAIL PROTECTED]>, "M. Warner Losh" writes: >I like this idea as well... > >Poul, maybe we should implement this on FreeBSD. > >I'd suggest "working_time_t" or "correct_time_t" as the name of the >type to replace "time_t" which would be deprecated. :-) plenty_time_t :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Fixing POSIX time
In message <[EMAIL PROTECTED]>, Neal McBurnett writes: >On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote: >> Assign different timescales very different >> numeric epochs: >> TAI:1972-01-01 00:00:00 UTC > >For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. I chose the time when TAI became constant rate so that all the rubber seconds are confined to negative values. >> UTC:MJD's epoch. > >That would be midnight in Greenwich of 1858-11-17. I don't see the >connection, and picking a time for which we don't know UT1 pretty >accurately and authoritatively will cause all kinds of arguments. Well, any number will do, as long as the epoch is unique (also with respect to time_t. >> UT1:Flamsteads birthday ? >Cute. 1646-08-19 > >> NTP:defined in RFC1305 > >== 1900-01-01 It's all magic numbers and as such they don't have to give any meaning. We could just pull out a random number for each and define that as the value of the timescale at some particular well defined point in time, so it could be something like: at 2006-03-01 00:00:00 UTC the timescales will have the following values: TAI:N1 UTC:N2 UT1:N3 etc. Given that all the timescales count in SI seconds, that would leave a bit of math for people to build the conversion tables, but that could be a task to be done only once. I like giving magic numbers som kind of meaning though, if nothing else to honour birthdays of people who deserve it. >> Small platform implementations can use a smaller width, >> for instance 64 bits split 48/16 and easily transform >> to standard format by zero extension. > >That would work for 9 million years or so. Plenty, but the point is that bigger computers are multiple of 32 or these days 64 bits, so chosing 48 bits is just wasted space and trouble on those. >> Different epochs will make it painfully obvious when people >> mix but don't match timescales in low quality implementations. > >Now we just need a name for the proposal I _really_ don't care what it's called, as long as it's defined correctly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: Fixing POSIX time
I like this idea as well... Poul, maybe we should implement this on FreeBSD. I'd suggest "working_time_t" or "correct_time_t" as the name of the type to replace "time_t" which would be deprecated. :-) Warner
Fixing POSIX time
On Thu, Jan 19, 2006 at 12:59:42PM +0100, Poul-Henning Kamp wrote: > I would far rather we tried to define a time API for > POSIX to adopt that makes sense. > > By make sense I mean: > > o conforms to relevant international standards > ie: recognizes the defininition of leap seconds since > for all purposes and intents we're probably stuck with > the blasted things for another 20 years. > > o is workable from a computer architecture point of view > no more pseudo-decimal timeval/timespec idiocy. > > o Caters to the needs of relevant user communities. Now you're talking sense, Poul! Thanks for your proposal. > Here's a strawman: > > Use a 128 bit signed integer. > > Assign the top 120 bits as one integer field with > resolution of 1/2^56 seconds. > > Assign the bottom 8 bits to an enum containing the > timescale in question. > > Assign different timescales very different > numeric epochs: > TAI:1972-01-01 00:00:00 UTC For TAI I'd suggest 1958-01-01, when TAI and UT were set nearly together. (I've seen more specific references that TAI was set according to both UT2 and UT1 - but they weren't the same then. Perhaps within known error at the time?) > UTC:MJD's epoch. That would be midnight in Greenwich of 1858-11-17. I don't see the connection, and picking a time for which we don't know UT1 pretty accurately and authoritatively will cause all kinds of arguments. I'd pick 1972-01-01, after the rubber-second era, and so that there is an integer number of seconds difference, as usual. > UT1:Flamsteads birthday ? Cute. 1646-08-19 > NTP:defined in RFC1305 == 1900-01-01 > Define functions to convert from one timescale > to another and define ERANGE as a return value when > outside the functions ability to do so (ie: future > dates on UTC). > > Define a compact ascii (no i18n!) representation for machine > readable use. (Ie: XML, protocols etc). > > Very clearly spell out that any timezone adjustments > must be carried out-of-band to this field. > > Assign the UTC timescale a identifier of zero. > > Advantages: > > Sufficient resolution to represent any likely physical > measurement or realizable frequency for the forseeable > future (13.8e-18 seconds resolution). > > Extracting the whole second part can be done by accessing > only the top 64 bits (which are enough to contain all > of history and then some). > > Conversion to/from NTP timestamps is trivial. > > Conversion to time_t is a matter of addition and extraction > of the relevant 32 bits. > > The binary format makes for fast and efficient arithmetic. > > By assigning the UTC timescale an identifier of zero, > the majority of implementations can disrecard the > multiple timescale aspect in total. > > Small platform implementations can use a smaller width, > for instance 64 bits split 48/16 and easily transform > to standard format by zero extension. That would work for 9 million years or so. > High quality implementations will check the bottom 8 bits > for identity and fail operations that mix but don't match > timescales. > > Different epochs will make it painfully obvious when people > mix but don't match timescales in low quality implementations. Now we just need a name for the proposal Neal McBurnett http://bcn.boulder.co.us/~neal/ > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > [EMAIL PROTECTED] | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence.
