Re: The real problem with leap seconds
On Tue, 10 Jan 2006, Mark Calabretta wrote: > On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote > in a message to: LEAPSECS@ROM.USNO.NAVY.MIL > > >I't be interesting to do an FFT on this list, and see if some of the > >contributers actually ever sleep, or do any other work... > > I had the same thought - the moreso when I reflect on the nil response > to my request for a counter-presentation at ADASS. > > (What sort of FFT did you have in mind?) One with a big value of F; unfortunatelly, the high frequencies would be lost because the differing implementations of the workaround for the broken POSIX notion of time make computation of TAI from the email timestamps problematic. Pete. > > Cheers, Mark >
Re: The real problem with leap seconds
On Mon 2006/01/09 10:38:54 -, Peter Bunclark wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL >I't be interesting to do an FFT on this list, and see if some of the >contributers actually ever sleep, or do any other work... I had the same thought - the moreso when I reflect on the nil response to my request for a counter-presentation at ADASS. (What sort of FFT did you have in mind?) Cheers, Mark
Re: The real problem with leap seconds
On Mon 2006/01/09 10:01:27 -, "Clive D.W. Feather" wrote in a message to: LEAPSECS@ROM.USNO.NAVY.MIL I've just read through the email that has accumulated on this list since before xmas - impressive volume! Why not devote a fraction of that time and energy to producing a formal position paper. >You've expressed it very badly in the article. ...and you've expressed this rather tactlessly! >The problem is not that UTC >can't be expressed as a real number. Rather (and you do sort of say this, >just not very well), the function UTC(TAI) is not continuous and monotonic. I can't let this one pass - UTC is continuous and monotonic. In fact, ignoring differences in origin, UTC = TAI. Surprised? If so then you're confusing a quantity with its representation (though in good company in doing so). First consider a graph of a person's age versus calendar date with a precision of 1 day. The fields in calendar dates are mixed-radix, the day field is also variable-radix depending on the month, and for February the year, so how should we plot the calendar axis? Simple, do it as a count of days and then label it with year, month and day-of- month; Feb/29 in leap years comes out in the wash. As expected, the graph is a continuous straight line of slope 1 - no breaks, no kinks - the person doesn't age in fits and starts! Now consider extending this graph to sub-second precision, accounting for leap seconds, with age to be measured in TAI and calendar date in UTC. Now the date axis must be constructed as a count of seconds of UTC (SI seconds, same as TAI) measured from birth. As before label the date axis using conventional calendar/clock notation. The graph is still a continuous straight line of slope 1 (no breaks, no kinks). Leap seconds are labelled as 23:59:60 - that is the formal representation, each second of UTC has a unique label as required for mathematical validity. (Note that it is incorrect to repeat the seconds count at 59, 00, 01 or anywhere else, even though that may be required on clock displays for practical reasons.) Doing arithmetic on UTC using clock notation is like doing arithemetic on calendar dates or with numbers using Roman numerals. The principle difference is that leap days follow a set rule and computations involving future times can be performed, whereas leap seconds do not follow a set rule and computations cannot be performed into the future. I am reminded of a discussion concerning the curious repetition of "1828" in e = 2.718281828... Simply reexpress the number in base 2, base e, or something else; the pattern disappears. Mark Calabretta ATNF
Re: The real problem with leap seconds
> >and you still cannot even get it [TAI] reliably from your > >average local NTP server. > > This is a circular argument: The reason NTP doesn't provide it > is that time_t needs UTC. No, I asked David Mills about 15 or so years ago why NTP distributes UTC and not TAI (me thinking and suggesting that it would have been so much better if NTP distributed TAI) and the reason was quite simple: There was no convenient way to get TAI. The time signals broadcast by WWV and WWVB in the US distributed UTC and leap warning bits, but did not distribute (and still do not AFAIK) what the TAI offset is. GPS receivers were (very) rare back then, so getting GPS time and subtracting out the constant offset to get back to TAI was not a viable option either (though perhaps it would be today, as long as the GPS system keeps running). I still think NTP should have distribute TAI, but I understand using TAI was not practicable option when NTP was designed. BTW, I don't know if the Fuzzball OS had any Posix time_t's in it, or anything resembling them, but I suspect not. I vaguely recall hearing that it had some other way of keeping the time in a collection of 16-bit registers (PDP-11s, don't you know). -Tim Shepard [EMAIL PROTECTED]
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Markus Kuhn writes: >and you still cannot even get it reliably from your >average local NTP server. This is a circular argument: The reason NTP doesn't provide it is that time_t needs UTC. -- 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: The real problem with leap seconds
From: Markus Kuhn <[EMAIL PROTECTED]> Subject: Re: [LEAPSECS] The real problem with leap seconds Date: Mon, 09 Jan 2006 19:12:05 + > "M. Warner Losh" wrote on 2006-01-09 16:57 UTC: > > There's been many many many people that have tried to fix POSIX time_t. > > One person's "fix" is another person's "recipe for disaster" ... True. All the fixes are worse than the disease. However, let us not forget that the disease is still bad. > The POSIX definition of time_t is not quite as broken as some > individuals would like you to believe. It actually does its job very > well, especially out there in the real world, where UTC is easily and > reliably available from many, many, independent channels. True. > The same > surely could not (and probably still cannot) be said for "TAI" and for > automatic leap-second table updates. You cannot get TAI from the BBC > evening news, and you still cannot even get it reliably from your > average local NTP server. False. Leap second tables are readily available. Current offset between UTC and TAI is generally available (or computable) from many time broadcasts (although not all). > (I know, we've already discussed this here, on [EMAIL PROTECTED], on > pasc-time-study, and on austin-group-l in *very* great detail, many, > many, many times, so I'll stop.) POSIX's time_t is broken. Very broken. It is broken accross leap seconds, and other times. It is convenient because one can get a decent notion of UTC from many places. However, it is equally easy to get a notion of TAI time as well, with very minimal effort. One can easily look on IERS' web page, or download the current leap second table from ftp://time.nist.gov/pub/leap-seconds.list with very minmal effort. When you have a leap second table, you can run in TAI and compute intervals correctly. When you don't have a leap second table, you can run in UTC, but cannot compute intervals correctly (accross leap seconds). Which set of problem do you want to have? The answer will very much depend on how connected you are and what the negative consequences are of computing time intervals wrong are. My applications tend to be unconnected with big consequences if intervals are computed wrong, which is the worst of both worlds. Anyway, time_t is like goto. Sure, you can use it. Sure it usually won't get you into trouble, but it is being badly abused and that abuse causes real problems for people that care about accuracy. Warner
Re: The real problem with leap seconds
"M. Warner Losh" wrote on 2006-01-09 16:57 UTC: > There's been many many many people that have tried to fix POSIX time_t. One person's "fix" is another person's "recipe for disaster" ... The POSIX definition of time_t is not quite as broken as some individuals would like you to believe. It actually does its job very well, especially out there in the real world, where UTC is easily and reliably available from many, many, independent channels. The same surely could not (and probably still cannot) be said for "TAI" and for automatic leap-second table updates. You cannot get TAI from the BBC evening news, and you still cannot even get it reliably from your average local NTP server. (I know, we've already discussed this here, on [EMAIL PROTECTED], on pasc-time-study, and on austin-group-l in *very* great detail, many, many, many times, so I'll stop.) Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
Re: interoperability
On Mon 2006-01-09T09:59:43 -0700, Rob Seaman hath writ: > Perhaps we might now bring the cartographic community inside the > firewall and clue them into what is being proposed? The cartographic community is effectively the IERS (short for the new IERRFS). They define all global systems of terrestrial and celestial measurement. Curiously, they do it not in accord with the railroaded Greenwich must be zero (oops, we really meant the other Greenwich, oh well, sorry all you folks who have Ordnance Survey maps) result of the 1884 IMC, but rather in more accord with the dissenting opinion of Janssen, the astronomer delegate from France. (A curious historical note is that Newcomb apparently recognized the validity of Janssen's notions at the IMC, but 20 years later in his memoirs Newcomb denied that.) The principal reason that we are not arguing ex post facto about a change to UTC which has already been implemented is that the original definition of UTC involved (at least at some points in its drafting) diplomatic relations between enough different agencies to require two hands worth of fingers when counting. -- 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: interoperability
Rob Seaman scripsit: > >This is like the "day is light and night is dark" statement: there > >is, at any given location, one and only one sunrise per (solar) > >day, no matter what clocks say. > > Communication prospers when people's clear meaning is not subjugated > to petty grammarians. My point was that your rhetorical flourishes have run away with you on more than one occasion. > We are now - and have been - discussing timekeeping changes that call > into question the definition of a "day". Those of us who support > solar time are fundamentally asserting the primacy of the the > standard day over the standard second (for civil timekeeping > purposes). Those of us who consider solar time to be a curious > anachronism, assert the the SI second over the concept of a day (for > civil timekeeping purposes). I agree with this assessment, more or less. > >As I've pointed out before, future times in legal documents are > >defined as LCT for a particular place, since the future mapping > >between LCT and any other time scale is not known. > > At the risk of igniting a new round of "stage two" nonsense, consider > the implications of your statement. Currently LCT (as you appear to > mean it) is standard time. Daylight saving (under whatever name) is > merely an overlay on standard time. Standard time has no jumps > (except for leap seconds). > > Under your suggestion, LCT would include the jumps for daylight > saving time (if locally used) as well as the jumps to correct for the > cumulative effect of tidal slowing. As I hope I have established, > these are "fall back" discontinuities that would result in the same > hour of LCT occurring twice. Is this not perceived to be a problem? Perhaps the problem here *is* merely semantic. By LCT I mean legal time, the time that de jure or de facto is observed in any given place (New York time in New York, Podunk time in Podunk, and Squeedunk time in Squeedunk). That includes all periodic or secular changes. And although periodic changes are far more common, secular changes for reasons of public convenience are *far* from unknown. I will try to say "legal time" from now on, though there are parts of the world (Antarctica, the oceans) where there is no legal time strictly speaking, and de facto time rules. It *is* a problem that some instants of (TAI/UTC) time have the same LCT labels in certain time zones. But it's a problem that we already deal with once a year. TV stations, for example, normally broadcast the same program twice in a row on Leapback Sunday, at least in the U.S. -- John Cowan [EMAIL PROTECTED] www.ccil.org/~cowan www.reutershealth.com The penguin geeks is happy / As under the waves they lark The closed-source geeks ain't happy / They sad cause they in the dark But geeks in the dark is lucky / They in for a worser treat One day when the Borg go belly-up / Guess who wind up on the street.
Re: interoperability
On Jan 9, 2006, at 1:22 AM, Clive D.W. Feather wrote: At some point, probably around the time that we're seeing an hourly shift every year, people are going to have to divorce "second" from "day", or at least re-negotiate the terms of engagement. By what magic do we believe the issues involved will become more tractable "at some point" in the future? How precisely does one divorce the definition of the day from that of the second? What is a clock if not a device to slice days into seconds? The fundamental problem is that the second is defined against one underlying concept of time and the day against another. As such, there are only three options: 1) redefine the "day" 2) redefine the "second" 3) occasionally reset the clock The only one of these that doesn't beg for a truly vast amount of use case and requirements analysis is #3, the status quo. I suspect most of us would be happy to pursue the research needed by either or both of the first two options. How much more interesting than letting our pasty complected cave dwelling descendants have all the fun! Rob
Re: interoperability
On Jan 9, 2006, at 1:01 AM, Clive D.W. Feather wrote: We go through such discontinuities twice a year in most years. Only the uninteresting daylight saving jumps. UTC remains without discontinuities above the level of a leap second. If UTC weren't equivalent to what I call "civil time", the ITU wouldn't be making a fuss to change it. Except that time zone shifting means you don't affect the UTC sequence. Only because you would redefine UTC to be equivalent to TAI. The proposal is simply to have this jump abolished, so that the UTC meridian starts drifting around the earth. Glad to see somebody admit that this is one of the issues in play. Perhaps we might now bring the cartographic community inside the firewall and clue them into what is being proposed? Note again that the implications of this are not somehow to be embargoed for 600 years, but rather would apply immediately and at all times between. Rob
Re: The real problem with leap seconds
In message: <[EMAIL PROTECTED]> Peter Bunclark <[EMAIL PROTECTED]> writes: : On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: : > : > I don't think anybody dare even think about redefining POSIX time_t : : I wish people would stop making positive assertions about what other : people are bound to think. What you mean in is, YOU are against : suggesting changing (or augmenting) POSIX time. : : I't be interesting to do an FFT on this list, and see if some of the : contributers actually ever sleep, or do any other work... There's been many many many people that have tried to fix POSIX time_t. They have all met with great resistance from the standards committee. I'm guessing that these well documented cases are what phk is familiar with when he makes statements like the above. Warner
Re: interoperability
On Jan 9, 2006, at 12:20 AM, Poul-Henning Kamp wrote: I think this shows how little you understand of the entire thing. Quite right! Hear, hear! But what I do understand has yet to be demonstrated to be fallacious. Several SI units are defined relative to the second these days and therefore everybody involved in metrology have had nothing but contempt for the notion of changing the second length. "Contempt" is a strong word, but I agree with your assessment - as the link provided also demonstrated. Your further ad hominem comments I discount out of regard for the list. I renew the offer to buy you a beer at some future meeting. Rob
Re: interoperability
On Jan 9, 2006, at 12:23 AM, John Cowan wrote: This is like the "day is light and night is dark" statement: there is, at any given location, one and only one sunrise per (solar) day, no matter what clocks say. Communication prospers when people's clear meaning is not subjugated to petty grammarians. We are now - and have been - discussing timekeeping changes that call into question the definition of a "day". Those of us who support solar time are fundamentally asserting the primacy of the the standard day over the standard second (for civil timekeeping purposes). Those of us who consider solar time to be a curious anachronism, assert the the SI second over the concept of a day (for civil timekeeping purposes). As I've pointed out before, future times in legal documents are defined as LCT for a particular place, since the future mapping between LCT and any other time scale is not known. At the risk of igniting a new round of "stage two" nonsense, consider the implications of your statement. Currently LCT (as you appear to mean it) is standard time. Daylight saving (under whatever name) is merely an overlay on standard time. Standard time has no jumps (except for leap seconds). Under your suggestion, LCT would include the jumps for daylight saving time (if locally used) as well as the jumps to correct for the cumulative effect of tidal slowing. As I hope I have established, these are "fall back" discontinuities that would result in the same hour of LCT occurring twice. Is this not perceived to be a problem? Rob
Re: interoperability
On Jan 9, 2006, at 12:08 AM, Poul-Henning Kamp wrote: In message <[EMAIL PROTECTED]>, Tom Van Baak writes: What if some killer app 40 years hence requires 100 ms or 1 ms time accuracy. You mean like mobile phones and optical tele networks ? Such infrastructure requires a precision *relative* timescale. I believe Tom's argument hinged on infrastructure that might evolve to require a precision *absolute* timescale. These are very different things.
Re: interoperability
On Jan 9, 2006, at 12:06 AM, Poul-Henning Kamp wrote: You yourself defined stage one as "TAI with some constant offset" yourself, you can't change definition in the middle of the discussion. I was attempting to describe your position. In point of fact, I agree with Tom Van Baak: You cannot divide timekeeping, time dissemination, into neat stages. What we can do, however, is layer our standards upon a coherent vision of the requirements placed on timekeeping by the wide range of activities engaged in by humanity. Talking to other humans aside from the 114 members of this list might be a good first step. I've never been in favour of the leap-hour proposal as other than a political instrument to be abandonned well before the clock strikes. Just wanted to re-emphasize your position. Considering that you and I, the polar extremes of this issue, both reject the notion of leap hours, perhaps we can find something else to talk about? Not adjusting the clock is less disruptive than doing so, no matter which half of the year. Won't repeat my arguments a third time. They have 600 years to find a solution and an implementation date for it. Who is this "they" you're talking about? We're discussing changing a standard that will be in effect now, then, and all times in between. Our descendants won't be appreciably smarter than we are, and they won't have access to insights regarding fundamental public timekeeping issues that we don't have. If we cannot posit a solution more creative than "forget the whole thing" (which I continue to assert is not an option, outside of extremely dark post-apocalyptic science fiction tales) then neither will they. Rob
Metas confirms HBG did fail
I just received email from Gregor Dudle at Metas and he confirmed that HBG did bungle the leap second. He says the bug is found and fixed "for the case there should ever again be a leap second" -- 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: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather" writes: >Poul-Henning Kamp said: >> So the standards crew, POSIX, LSB or whoever would have to come up >> with a new data type for holding timestamps, > >We already have one: struct tm. Doesn't work. Struct tm is defined such that if you do tm.tm_sec += 75 the "right" thing will happen. That is why, as Warner has documented that the leapsecond has a time_t one less than what you get out of timegm(23:59:60), the "60" second count is normalized to 00:00:00. -- 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: The real problem with leap seconds
Poul-Henning Kamp said: > So the standards crew, POSIX, LSB or whoever would have to come up > with a new data type for holding timestamps, We already have one: struct tm. > There is no doubt that from a humanistic point of view it would be > better to educate all the programmers, but considering that I still > suffer from web-forms that insist I enter a USA style phone number > when I have entered "Denmark" as country, this is a far moure > daunting task than it might appear. Amen. [I happen to have a US Social Security number, which allows me to confuse some web pages back.] -- 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: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, Peter Bunclark writes: >On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: >> >> I don't think anybody dare even think about redefining POSIX time_t > >I wish people would stop making positive assertions about what other >people are bound to think. What you mean in is, YOU are against >suggesting changing (or augmenting) POSIX time. No, I mean exactly what I wrote: "I don't think anybody dare even think about redefining POSIX time_t" The reason I mean that is that I've talked to a lot of the relevant people and they're all totally morified about the consequences of (time_t % 86400) not giving you the time of day. Remember, most of these people are even afraid to extend time_t to 64 bits because of the possible fall-out :-( -- 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: The real problem with leap seconds
I wrote: > Right now, the DTAI(TAI) function is the sum of a set of Kroneker delta > functions. Thanks to David for quietly pointing out that I meant Heaviside step functions, not Kroneker delta functions. -- 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: The real problem with leap seconds
On Mon, 9 Jan 2006, Poul-Henning Kamp wrote: > > I don't think anybody dare even think about redefining POSIX time_t I wish people would stop making positive assertions about what other people are bound to think. What you mean in is, YOU are against suggesting changing (or augmenting) POSIX time. I't be interesting to do an FFT on this list, and see if some of the contributers actually ever sleep, or do any other work... Pete.
Re: The real problem with leap seconds
In message <[EMAIL PROTECTED]>, "Clive D.W. Feather" writes: >The real problem is not the 23:59:60, it's *predicting* when they happen. I agree, the short prediction horizon is the major problem. But 23:59:60 _is_ a problem too. I don't think anybody dare even think about redefining POSIX time_t and even if they did redefine it to contain leap-seconds, many tons of software wouldn't be updated/recompiled to take advantage of it. So the standards crew, POSIX, LSB or whoever would have to come up with a new data type for holding timestamps, and while a number of proposals have been floated over the years, none of them seem to contain any real clue, so I don't think this is likely to happen. But pressume for a moment that they did come up with a new standard, the many tons of software would still not be rewritten to take advantage of it, so we'd still be stuck with time_t's ostrich behaviour for the forseeable future. Unlikely as it is, it would allow people like Warner and me to write software that Do The Right Thing. A far more sensible idea is to just forget about leap-seconds from now on, leave DUT1 to wander, tell BIPM/IERS to provide a contemporary kind of service (internet services instead of handwritten letters), the astronomers to shut up&cope and leaving the issue of the length of day in 500 years to the people who live 500 years from now on. It's the comparison between educating all programmers in the world vs having the astronomers use a DUT which is larger than 1 second. There is no doubt that from a humanistic point of view it would be better to educate all the programmers, but considering that I still suffer from web-forms that insist I enter a USA style phone number when I have entered "Denmark" as country, this is a far moure daunting task than it might appear. 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: The real problem with leap seconds
Michael Sokolov said: > http://ivan.Harhan.ORG/~msokolov/articles/leapsecs.txt > > The short summary is that I believe the root problem is not the > adjustments made to the civil time scale to match Earth's rotation, but > the fact that UTC is not expressible as a real number. Read the article > for a detailed explanation of what I mean by that. You've expressed it very badly in the article. The problem is not that UTC can't be expressed as a real number. Rather (and you do sort of say this, just not very well), the function UTC(TAI) is not continuous and monotonic. Right now, the DTAI(TAI) function is the sum of a set of Kroneker delta functions. It is thus monotonic but not continuous (though only discontinuous in a few places). It is, of course, real. > I encourage both pro- and anti-leap second advocates on this list to > read my article since there is that slight possibility that the problem > I point out (which I haven't seen anyone else point out so far) It's one we've all been aware of for ages. > and the > solution I propose which is Markus's UTS with trivial alterations > my proposal would allow civil time to be well > anchored to Earth's rotation without causing grief for computer systems > like leap seconds currently do. On the contrary, it would cause exactly the same grief. If your proposal was a wonderful solution, then leap seconds would not be a problem either because the two are trivially mappable (I'm assuming that there'd be a "rubber second" flag). The real problem is not the 23:59:60, it's *predicting* when they happen. -- 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: interoperability
In message <[EMAIL PROTECTED]>, Steve Allen writes:
>On Mon 2006-01-09T08:20:40 +0100, Poul-Henning Kamp hath writ:
>> beginning ("SI seconds are constant length").
>
>Yes, SI seconds are constant length, but the ghost of my general
>relativity teacher prompts me to assert that my SI seconds are not
>equal to your SI seconds because we are in different reference
>frames.
>(This has nothing to do with leap seconds, [...]
You are absolutely right there, so why even bring it up ?
--
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: interoperability
Rob Seaman said: > I have heard no response to my discussion of techniques for achieving > synchronization - of the difference between naive "fall back" hours > and 25 hour days. But how in practice is it envisaged that a scheme > for migrating time zones versus TAI would work, precisely? In the short term, by modifying the UTC-LTC function by adding a secular term to the periodic one. Thus at present the function in the UK is: dayofyear in [Last Sunday in Mar .. Last Sunday in Oct] ? 3600 : 0. This would change to: (dayofyear in [Last Sunday in Mar .. Last Sunday in Oct] ? 3600 : 0) + (year < 2600 ? 0 : year < 3100 ? 3600 : year < 3500 ? 7200 : ...) or whatever. Note that we already have similar levels of complexity in dealing with the changing summer time dates, the British Standard Time folly, BDST during the war, and so on. Note also that the Olsen tz code handles all of this just fine. > Note, for > instance, that nothing short of redefining the second can avoid the > quadratic acceleration between the stage one and stage two clocks. > Time zones (and the prime meridian?) would race more-and-more rapidly > around the globe. At some point, probably around the time that we're seeing an hourly shift every year, people are going to have to divorce "second" from "day", or at least re-negotiate the terms of engagement. -- 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: interoperability
On Mon 2006-01-09T08:20:40 +0100, Poul-Henning Kamp hath writ:
> beginning ("SI seconds are constant length").
Yes, SI seconds are constant length, but the ghost of my general
relativity teacher prompts me to assert that my SI seconds are not
equal to your SI seconds because we are in different reference
frames.
The rate at which TAI ticks has been modified several times to meet
improved notions of whose SI second it should really try to match.
The current notion is that of a coordinate time scale at a depth in
the geopotential field which is close to mean sea level.
Such a coordinate time scale cannot be extended very far from the
surface of the earth without requiring some fascinating corrections
to the rates measured by different observers.
Tom Van Baak can show you how measuring this is now child's play.
Why should my lab use TAI when the proper time experienced by my
real-time control processes runs at a different, and continually
varying, rate?
The answer is the same as for UT defined by Newcomb's expression used
from 1901 through 1983 and implemented via astronomy: it is the most
practical uniform time scale that we all can agree upon.
For current purposes with stationary clocks the varying terms in the
rate differences are immeasurable. In the limit of very precise lab
timekeeping eventually the question arises as to whether TAI really is
the most suitable scale for some applications.
(This has nothing to do with leap seconds, but does raise the question
of the limits at which it becomes much more difficult to agree on 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
Re: The opportunity of leap seconds
On Sun, 8 Jan 2006, Tom Van Baak wrote: > Peter, > > So where do these modern telescope get UT1? Do you or The last time I was involved personally was during my time as a support astronomer at the Isaac Newton Group on La Palma in the early nineties. We had a radio receiver which required upcoming leapseconds to be entered manually ahead of time. This provided a one second per second UTC interrupt to the telescope control computers. The TCS computers were programmed with an upcoming leapsecond, and with the corresponding jump in DUT1. To compute fractions of a UTC second, the computer adds its own clock to the one-second interrupt count, which gives high precision. The whole system gives UT1 to high precision throughout a leapsecond event and beyond. Pete.
Re: interoperability
Rob Seaman said: > The question of delivering wall > clock time is a trivial elaboration on first delivering common > international business time. (I'm trying on different terminology > than "civil time" until I hit one that sticks.) I don't accept that the concept exists. The international business community still works - as far as I can tell - on the equivalent of "Hello Fred, what time is it there?". > The event of migrating a time > zone is a discontinuity just as with a leap second or leap hour. So what? We go through such discontinuities twice a year in most years. Some places more often. Read the TZ list archives. > What matters is not when sunrise occurs, but rather that every day > has one (and only one). Something which isn't and hasn't been true in many places. What time is sunrise in Tromso today? What time was sunrise on 1994-12-31 in eastern Kiribati? >> If Denmark or Elbonia decides to use a timezone which is offset >> from stage one by 1h3m21s, then it still works, > Again, what is "it", precisely? Life. >> (but people travelling abroad will probably vote differently in the >> next election) > Exactly. The pressures to maintain a common international vision of > time will trump local variations. That's not pressure to maintain a common international vision, but people not wanting to fiddle with the minutes and seconds on their digital watches. >> In a couple of hundred years, the Danish Parliament (or its >> successor in interest) will simply decide "from -MM-DD HH:00, >> the Danish Civil time will use offsets -3h and -2h (instead of >> presently -1h/-2h) and the transition will happen on the switch >> from summertime to wintertime by _not_ adjusting the clock". > The only way this differs from the leap hour proposal is that you are > assuming that different localities can (or would) carry these > adjustments out separately. > > Let's see - how does this work? Just the way that it does right now. > Under the current standard, 3600 small steps > would have bled away the pressure. Under the ITU notion, a leap hour > would be needed. A leap hour means moving UTC backward one hour (to > let TAI pull ahead). As I've said before, under the daylight saving > analogy this is only naively a "fall back" event, it would be better > to explicitly add a 25th hour. But let's continue through to the > logical conclusion of implementing this via "fall back" events (or > the equivalent time zone shifting). Except that time zone shifting means you don't affect the UTC sequence. > A fall back event means that the clock (local, standard, > international, whatever clock you want) first traverses an hour - and > then traverses it again. Right. At present, there's a meridian corresponding to UTC that starts at Greenwich, drifts back and forth with secular changes in the earth's rotation and, when it approaches Cutty Sark or the Dome suddenly jumps. The proposal is simply to have this jump abolished, so that the UTC meridian starts drifting around the earth. > Um. How does one redefine the length of the day without changing the > length of the second? Answer: by changing the number of seconds in > the day. I won't belabor the difficulty of selling the idea of > having different hours of different lengths. You mean just like now? -- 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||
