Re: The opportunity of leap seconds
On Sat, 7 Jan 2006, Poul-Henning Kamp wrote: What Astronomers use UTC for, in your own many times repeated words, is a convenient approximation of UT1, and consequently it follows that if instead of an approximation astronomers used the Real Thing, leap seconds could harmlessly be removed from UTC. Too simple; many old telescopes, with equatorial mounts, such as the historic telescopes at the Institute of Astronomy where I work, do indeed use UTC as a UT1 approximation. The time error involved in this is a small offset in one axis which you calibrate out on a clock star. Research-quality telescopes, in particular all the ones built in the last few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error would be a complex ~10 arcsec error in both axes and give a quite useless pointing performance. However, UTC is often used as a UT1 delivery system; because it's an international standard, and is widely available, and DUT1 is guarenteed to be less than 0.9s, it's a natural choice for supplier of time. Interestingly, because control algorithms tend to be rigorous, a large DUT1 probably would be ok in itself (there would be a cost involved in checking that this would be so) but certainly in the case of a couple of telescope control systems of which I have the required knowledge, the DUT1 input method does a 0.9 second range check. Peter.
Re: The real problem with leap seconds
Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Since the usual response of the pro-leap second lobby to people who want a uniform timescale is use TAI this is significant. Do you have any information or references on why the BIPM director said this? Ed.
Re: The real problem with leap seconds
In message [EMAIL PROTECTED], Ed Davies writes: Wow, things have got really stirred up around here. Lots of interesting points but I'll just concentrate on one... Poul-Henning Kamp wrote: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year, and I can see where he is coming from on that one. Since the usual response of the pro-leap second lobby to people who want a uniform timescale is use TAI this is significant. Do you have any information or references on why the BIPM director said this? As I understood it, it was mainly that TAI is a post-factum postal timescale. -- 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 opportunity of leap seconds
On Sun 2006-01-08T12:41:21 +0100, Poul-Henning Kamp hath writ: It sounds to me like BIPM ought to make an Internet service available which will deliver UT1 to astronomers in a timely fashion ? That would have to be the IERS. Something as simple as finger [EMAIL PROTECTED] Or even just a more stringent formatting of the bulletins on the ftp site could do it as well. I do not believe that any of the IERS bureaus have internet connections and servers which are anywhere near robust and redundant enough to make that a reliable service. There is a lot that could and should be done. The USNO branch of the IERS issues two files with predictions about earth orientation every Thursday. It is not widely known that last July on the Thursday following the Daniel Gambis announcement one of those files acknowledged the leap second we just experienced, and the other did not. This was fixed with a new release which happened by Friday. (Despite some NTP servers which reportedly still have not acknowledged the leap second, I think the overall indications are that the NTP network did better than 50 %.) The existing IERS system is dysfunctional. -- 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: predicting leap seconds
On Jan 7, 2006, at 11:01 PM, M. Warner Losh wrote: This would phase in the predictive timeline for leap second insertions, and would also give the IERS control to end the experiment if the time horizons exceeded their ability to predict with confidence. it would also be completely within the current UTC specification and practices. The various bulletins are required to be released with a minimum look-ahead schedule. No particular reason they might not issue a bulletin every six months including both scheduled leap seconds and unscheduled predictions in a sliding window extending forward a decade or more.
Re: The opportunity of leap seconds
On Jan 8, 2006, at 4:41 AM, Poul-Henning Kamp wrote: It sounds to me like BIPM ought to make an Internet service available which will deliver UT1 to astronomers in a timely fashion ? Not sure BIPM is necessarily the appropriate agent, but otherwise agree 100%. Perhaps we should seek other areas of agreement rather than continually focusing on issues in hot debate. Both this and the extended leap second scheduling represent improvements to infrastructure that would also support market-based decision making about civil time issues in general. The current timekeeping landscape is simply too sparse to create significant emergent behavior.
Re: The real problem with leap seconds
On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not?
Re: The opportunity of leap seconds
In message [EMAIL PROTECTED], Steve Allen writes: Something as simple as finger [EMAIL PROTECTED] Or even just a more stringent formatting of the bulletins on the ftp site could do it as well. I do not believe that any of the IERS bureaus have internet connections and servers which are anywhere near robust and redundant enough to make that a reliable service. There is a lot that could and should be done. I'm certainly starting to get the impression that a modernization project to move the time-lords a few decades forward would not be out of order. (Despite some NTP servers which reportedly still have not acknowledged the leap second, I think the overall indications are that the NTP network did better than 50 %.) My estimate is 50-70% of the pool.ntp.org servers did something close enough to the right thing. -- 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], Steve Allen writes: On Sat 2006-01-07T21:20:33 +0100, Poul-Henning Kamp hath writ: Well, the BIPM doesn't really want anybody to use TAI, their director said as much last year The Italian contribution to the November 2005 WP7A meeting could be interpreted a suggestion that the international agencies in charge of time scales need to get their heads together, pick one time scale with no discontinuities, and abolish all others. That sounds like the sensible partys platform to me. Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Klepczynski had implied that more clearly on pages 322 and 323 of http://tycho.usno.navy.mil/ptti/ptti2004/panel.pdf where he discusses getting all the satellite navigation systems to use a single time scale. It is the time scale that is the issue, it's the clock offset between the systems. If you have 2 GPS sats, one GLONASS and one GALILEO, you also need to know the clock offsets between the three systems before you can calculate a position. If everybody gets their act together and hold the clock offsets small, then it would be a wonderful world indeed, but I think the practical, organizational and political problems will prevent that. The other option is for the systems to broadcast their clock offsets relative to the other systems. For that to help rapid first fix it must be a frequent broadcast (ie: non-almanac) otherwise you might as well just wait until you get four birds in one system. (And to see that psychology is not just relevant to astronomers, read Matsakis on page 336.) Yes, astronomers have psychology too, but the comments on that page has nothing to do with leap seconds at all. -- 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], Rob Seaman writes: On Jan 8, 2006, at 5:38 AM, Poul-Henning Kamp wrote: As I understood it, it was mainly that TAI is a post-factum postal timescale. One is left pondering the fact that UTC is now (and would remain under any changes I've heard suggested) a time scale based on TAI. What magic makes one acceptable and the other not? I didn't say I thought the protest against more widespread use made sense, I merely tried to relay it faithfully. I does sound consistent with previously mentioned old fashionedness. -- 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 opportunity of leap seconds
In message [EMAIL PROTECTED], Peter Bunclark writes: On Sun, 8 Jan 2006, Poul-Henning Kamp wrote: finger [EMAIL PROTECTED] You mean [EMAIL PROTECTED] That would be quiet useful. Otherwise let's not bother with NTP protocol, just [EMAIL PROTECTED] I don't really care what the service is called, but I agree that it should be simple :-) -- 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.
interoperability
On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Without further debating the meaning of civil time, consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Governments and technical users would subscribe to the first stage clock. Businesses and civilians would subscribe to the second stage clock(s). Correct so far? For the sake of argument, let's discount the risks associated with confusing one stage's clock with the other. One imagines, however, that there won't be fewer safety critical, time dependent systems in the future. We might, in fact, suspect that every party to this conversation would both admit this and use it to argue for their own position :-) Those risks, however, represent only one issue falling under the umbrella of interoperability. It is one thing to say that any random local government can choose their own clock statutes. This is certainly true, but in practice the future international community will work together to reach joint decisions on evolving common clock practices (as you say, just like today). I won't belabor the many worldwide systems that must interoperate for the benefit of all. But these systems must interoperate not only between themselves, but with natural phenomena. Forgive me (or don't), but I am skeptical that phenomena of interest in the future will not continue to include the rising and setting of the sun. (And isn't claiming otherwise equivalent to saying that stage two is unnecessary?) The question is: how precisely does this differ from the situation now or in the past? Whether by fiat or not, some common worldwide stage two clock must exist. And some mechanism must exist for synchronizing (to some level of tolerance that we can continue to debate) that clock to diurnal cycles. It is this synchronization that is ultimately of interest to us, not leap seconds, per se. 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? 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. Perhaps I've misunderstood, but this line of reasoning doesn't appear to resolve anything. Rob Seaman National Optical Astronomy Observatory
Re: The real problem with leap seconds
In message: [EMAIL PROTECTED] Poul-Henning Kamp [EMAIL PROTECTED] writes: : In message [EMAIL PROTECTED], Ed Davies writes: : Wow, things have got really stirred up around here. Lots of interesting : points but I'll just concentrate on one... : : Poul-Henning Kamp wrote: : Well, the BIPM doesn't really want anybody to use TAI, their director : said as much last year, and I can see where he is coming from on that : one. : : Since the usual response of the pro-leap second lobby to people : who want a uniform timescale is use TAI this is significant. : Do you have any information or references on why the BIPM director : said this? : : As I understood it, it was mainly that TAI is a post-factum postal : timescale. How is it that UTC can be realized in realtime, but TAI isn't. I thought the difference between the two was an integral number of seconds, by definition. Is that understanding flawed? Wanrer
Re: interoperability
In message [EMAIL PROTECTED], Rob Seaman writes: On Jan 8, 2006, at 9:09 AM, Poul-Henning Kamp wrote: Doing so would once and for all have to divorce earth orientation from that unified time scale, leaving it to governments to align civil time with daylight as they see fit (just like today). Without further debating the meaning of civil time, consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. Yes, too bad about the offsets (GPS etc) but as long as they don't change with short notice, they can be dealt with. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Yes, just like now. The DCF77 transmitter for instance sends out German legal time which means that if you want UTC from it, you need to know the UTC offset for summer/winter in Germany. Governments and technical users would subscribe to the first stage clock. Businesses and civilians would subscribe to the second stage clock(s). Correct so far? Almost. What you overlook here is that computers tend to trancend governmental boundaries. Sensibly designed operating systems keep time in the form of the first stage clock, and at the representation layer, knowing all the worlds governmental decisions about getting from 1st to second stage applies the appropriate conversions. Badly designed operating systems keep time in local time which makes interchange of information a nightmare across timezones. Windows have got it right now I belive, but it used to be that a file created and transmitted from Denmark at the end of the business day would be older than a file created at the start of business day in California, despite a strict ordering of the events. For the sake of argument, let's discount the risks associated with confusing one stage's clock with the other. That's actually the good thing about the constant offset, it should make it much easier to see if timestamps mix things that shouldn't be. I won't belabor the many worldwide systems that must interoperate for the benefit of all. But these systems must interoperate not only between themselves, but with natural phenomena. Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. You mention sunrise and sunset. Since the introduction of timezones, one of the things which were given up was the concept that sunrise/sunset happened on the same numerical time at any given lattitude. Denmark spans only a few hundred kilometers from east to west (not counting Greenland this time), yet sunrise and sunset varies about 30 minutes from one side to the other. Most people get the sunrise/sunset numbers out of the Almanac from the Copenhagen Universitys Observatory [2] which lists sun rise/set times for the observatory in Copenhagen and prints a table of approximate geographical adjustment factors. So already today, sunrise sunset can only be determined using auxillary tables of correction factors, tables which could trivially absorb the DUT correction in addition to the longtude corrections. The question is: how precisely does this differ from the situation now or in the past? Whether by fiat or not, some common worldwide stage two clock must exist. BZZZT wrong. The definition we started out with is: The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Conversion from stage two to stage one (and back) is perfect, so if I measure a supernova in Denmark on Danish Civil Time, I can mail you my observations and you can convert it first to stage 1 and then to your local stage 2 to compare with your own observation. Or more likely, convert your own stage 2 to stage 1 and compare in the scientific time domain. If Denmark or Elbonia decides to use a timezone which is offset from stage one by 1h3m21s, then it still works, (but people travelling abroad will probably vote differently in the next election) 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? The same way all changes in timezone seems to be carried out: by _not_ adjusting the clock when going to summer or winter time. 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. That's been done many times throughout the world already. If you look in NPL's decription of the Rugby timegrams:
Re: The real problem with leap seconds
On Sun 2006-01-08T11:44:04 -0700, M. Warner Losh hath writ: How is it that UTC can be realized in realtime, but TAI isn't. I thought the difference between the two was an integral number of seconds, by definition. Is that understanding flawed? I believe the claim would be that UTC(insert your national time service here) is realized in real time. UTC(USNO) is the official time of the US, and I suspect that there would be loss of face if any agency charged with keeping a national time did not, in some sense, proclaim autonomy. UTC(pick one) is, of course, directly related to TAI(pick one). TAI(anywhere) has no official status anywhere, except in the ex post facto statistical sense that it contributes to TAI (unmodified, the real thing from the BIPM). In an official sense of operational time scales, it is not clear that there really is anything such as UTC (plain old, unmodified) which differs from TAI by an integral number of seconds. As an identifiable entity, UTC (unmodified) may only exist within the text of ITU-R TF.460 -- 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
Research-quality telescopes, in particular all the ones built in the last few decades on alt-azimuth mounts, do of course use UT1; a 0.9s error would be a complex ~10 arcsec error in both axes and give a quite useless pointing performance. However, UTC is often used as a UT1 delivery system; because it's an international standard, and is widely available, and DUT1 is guarenteed to be less than 0.9s, it's a natural choice for supplier of time. Interestingly, because control algorithms tend to be rigorous, a large DUT1 probably would be ok in itself (there would be a cost involved in checking that this would be so) but certainly in the case of a couple of telescope control systems of which I have the required knowledge, the DUT1 input method does a 0.9 second range check. Peter. Peter, So where do these modern telescope get UT1? Do you or any other astronomers on the list know if they pick off bits from WWV (or equivalent SW or LF broadcast)? Or is there a nice thumbwheel switch in a control room that someone gets to advance anytime they get an IERS Bulletin by FAX or email? Or is it a software interface to the IERS website? I guess in all the years this list has operated, and with all the detailed anecdotes about leap seconds I've never heard details of how an observatory anywhere actually obtains, and uses, DUT1; and to what level of precision. /tvb
Re: interoperability
Without further debating the meaning of civil time, consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. Governments and technical users would subscribe to the first stage clock. Businesses and civilians would subscribe to the second stage clock(s). Correct so far? I think this was a fair description of the timekeeping world in the 1960s or even 1970s. But in the last 10 or 20 years, with the explosion in consumers of broadcast time and frequency services such as WWVB, DCF, GPS, and NTP, vast numbers of applications have direct access to the first stage; which effectively removes the power of the middle man, the government, the local authorities. What was your human technical user of 1970 is now the infrastructure of the cellular phone system or the hardcoded algorithms of an operating system or home appliance. The technical users of the 60s have coded themselves into products of the 90s. You cannot divide timekeeping, time dissemination, into neat stages. In the 1960s if ten labs were told to offset their phase or frequency it affected only a handful of people or systems. Today when IERS announces a leap second, millions of machines, systems, and people are affected. Thankfully, most of them handle it OK. /tvb
Re: interoperability
On Jan 8, 2006, at 4:04 PM, Tom Van Baak wrote: You cannot divide timekeeping, time dissemination, into neat stages. Again. My point is strengthened. This being the case, a requirement on one flavor of time transfers to others. We will not solve the problem of creeping complexity and interface violations by attempting to legislate the physical world out of the equation. Rather, it is the common baseline of mean solar time that will save us from our own follies. Whether it is a real number or not, it has the benefit of correspondence (now, and day after day, millennia after millennia) of mattering to humanity. I don't say it matters in critical detail for every purpose under the sun, rather it matters in broad strokes for many a purpose. I've got nothing against TAI and other flavors of interval time, they simply do not match the requirements for a common human oriented baseline. They are preferred for some technical purposes. They are most definitely not preferred in broad strokes over long periods of time to the bulk of our customers. The customer is always right. Rob
Re: interoperability
On 8 Jan 2006 at 15:04, Tom Van Baak wrote: You cannot divide timekeeping, time dissemination, into neat stages. In the 1960s if ten labs were told to offset their phase or frequency it affected only a handful of people or systems. Today when IERS announces a leap second, millions of machines, systems, and people are affected. Thankfully, most of them handle it OK. Although, even now, the majority of consumer and business equipment is not directly affected in any noticeable way; such machines usually run on a local clock considerably less accurate than an atomic clock, periodically re-synced (perhaps manually, perhaps automatically) to an external time standard. At each such re-syncing, the time may need to be adjusted by a few seconds, or even a few minutes, due to inaccuraccies in the local timepiece, so any leap second that may have occurred since the last syncing will merely result in a 1-second difference in the magnitude of this adjustment, not particularly noticeable to the end users. If some application (e.g., a database) requires a timescale without discontinuities, the application might need to be shut down for a few seconds to perform the time adjustment (whether or not there is a leap second in the mix) in order to prevent data corruption at the moment of the change. -- == Dan == Dan's Mail Format Site: http://mailformat.dan.info/ Dan's Web Tips: http://webtips.dan.info/ Dan's Domain Site: http://domains.dan.info/
Re: interoperability
You cannot divide timekeeping, time dissemination, into neat stages. In the 1960s if ten labs were told to offset their phase or frequency it affected only a handful of people or systems. Today when IERS announces a leap second, millions of machines, systems, and people are affected. Thankfully, most of them handle it OK. Although, even now, the majority of consumer and business equipment is not directly affected in any noticeable way; such machines usually run on a local clock considerably less accurate than an atomic clock, periodically re-synced (perhaps manually, perhaps automatically) to an external time standard. At each such re-syncing, the time may need to be adjusted by a few seconds, or even a few minutes, due to inaccuraccies in the local timepiece, so any leap second that may have occurred since the last syncing will merely result in a 1-second difference in the magnitude of this adjustment, not particularly Correct. This works for timepieces which are less than accurate to the second. And I believe this is why UTC and leap seconds are still today the most practical and accepted way to reconcile the unavoidable difference between astronomical and atomic timescales. The danger, though, is that in the 60s maybe ten systems were affected by leap seconds. In the 80s maybe a thousand. Today, the number of systems affected (or is it infected?) with leap second awareness is in the millions. I worry about this trend in the decades to come. I am a fan of leap seconds as a weird and curious nuisance but am not sure I like the idea that eventually my car, traffic lights, airlines, television, and my thermostat will have to be reliably tied to the IERS in order to function properly. Don't forget the quartz wristwatch is only 40 years old. What if cesium wristwatches show up 10 years from now. What if some killer app 40 years hence requires 100 ms or 1 ms time accuracy. Do we still want UTC leap seconds when it will infect ten billion devices? This is not an argument for change right now. But no matter how you look at it the current scheme does not scale well into the future; either a technological future (way too many devices affected by unscheduled time steps) or an astronomical future (way too many leap seconds a year). noticeable to the end users. If some application (e.g., a database) requires a timescale without discontinuities, the application might need to be shut down for a few seconds to perform the time adjustment (whether or not there is a leap second in the mix) in order to prevent data corruption at the moment of the change. I would guess your total shutdown solution gets less popular as time goes on. That's one reason why CDMA cell phones, most operating systems, and GPS use a TAI-like continuous timescale instead of UTC for their underlying timescale. /tvb
Re: interoperability
Rob Seaman scripsit: The question is: how precisely does this differ from the situation now or in the past? Whether by fiat or not, some common worldwide stage two clock must exist. Again, no it doesn't need to exist. We need a uniform time scale like TAI. And we need local civil time for all the 400-odd jurisdictions in the world today. If other people need other timescales (and they do), there's no reason that should affect the two requirements above. But how in practice is it envisaged that a scheme for migrating time zones versus TAI would work, precisely? Straightforwardly. Each locality decides when and how to adjust both its offset from TAI and its seasonal transition function (if any), just as it does today. What we abandon is a universal time tightly synchronized to Earth rotation in favor of a universal time independent of earth rotation plus 400+ local civil times roughly synchronized to Earth rotation containing various glitches. -- We pledge allegiance to the penguin John Cowan and to the intellectual property regime [EMAIL PROTECTED] for which he stands, one world underhttp://www.ccil.org/~cowan Linux, with free music and open source http://www.reutershealth.com software for all. --Julian Dibbell on Brazil, edited
Re: interoperability
In message [EMAIL PROTECTED], Rob Seaman writes: Sensibly designed operating systems keep time in the form of the first stage clock, Perhaps. We have no examples of this. Stage one would be TAI. As we have just been reminded, TAI is not ready for prime time. Stop. You yourself defined stage one as TAI with some constant offset yourself, you can't change definition in the middle of the discussion. Stage one is something like GPS time or UTC with no further leap seconds. Today stage one is UTC with leapseconds and all POSIX systems use that but fake the leapseconds. Badly designed operating systems keep time in local time which makes interchange of information a nightmare across timezones. You are arguing apples and oranges. These operating systems, in effect, use stage three clocks. No, you are confused. Perhaps I miss your meaning here, too. The event of migrating a time zone is a discontinuity just as with a leap second or leap hour. The discontinuity is not in the stage one timezone, but only in the governmental offset which defines stage two relative to stage one. We already have two of those discontinuitues a year most places and people and computers can live with them. People can live with them because they are big enough that you don't forget about them (for long). Computers can live with them because they use the stage-one timescale for representation. Denmark spans only a few hundred kilometers from east to west (not counting Greenland this time), yet sunrise and sunset varies about 30 minutes from one side to the other. This is true. It is irrelevant to the underlying international clock. These are simply constant (if position dependent) offsets. Big wup. I think this issue is confusing the discussion. No, they are actually very relevant because they show that you can't use a timescale as a vector component to locate extra terrestial objects without taking your longitude into account. daylight saving time is irrelevant. No. What matters is not when sunrise occurs, but rather that every day has one (and only one). DST is very relevant, as it is a much more feasible mechanism for holding the sun high in the sky on the civil timescale. Conversion from stage two to stage one (and back) is perfect, Don't believe a detailed enough proposal is on the table to either define the meaning of perfect in this context, or determine if the notion being discussed meets the requirements for being so regarded. I don't belive in science ? For any timestamp on the civil timescale any spot on earth, there exist a mathematical formula which will convert that timestamp to UTC and vice versa. 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? Your own proposal. stage one is atomic time (e.g., TAI) stage two is international civil time (e.g., UTC) stage three is local legal time (e.g., Mountain Standard Time) No. Now you try to change definitions under the discussion again. In your first email you defined it thusly: Without further debating the meaning of civil time, consider the implications of this two stage system. The first stage conveys TAI or something related to it by a constant offset. The second stage at any location (correct me if I misunderstand you) would be a secondary clock disseminated at the direction of the local authorities. In other words: (stage_zero is TAI) stage_one is TAI + constant stage_two is stage_one + governmental adjustment. 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. 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. And yes, I think you are likely to see far more governments fiddle with their respective civil time than scientists fiddle with UTC over the next 500 years, so I'm confortable leaving it to them. A fall back event means that the clock (local, standard, international, whatever clock you want) first traverses an hour - and then traverses it again. No, that's what happens every year when switch from summer time to winter time. When the need to reset the civil timescale that event does _not_ happen. This doesn't work because we're on the wrong side of the pendulum's arc. The point being that you don't need to *not* adjust the clock in the Autumn - you need to not adjust the clock in the Spring. Same argument: Not adjusting the clock is
Re: interoperability
Rob Seaman scripsit: Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. Perhaps I miss your meaning here, too. The event of migrating a time zone is a discontinuity just as with a leap second or leap hour. Sure. But discontinuities in LCTs are something we already know how to handle. This is true. It is irrelevant to the underlying international clock. PHK and I are denying any need for an international clock that tracks Earth rotation. What matters is not when sunrise occurs, but rather that every day has one (and only one). 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. Exactly. The pressures to maintain a common international vision of time will trump local variations. It is the resulting common international time clock that you won't let me refer to as civil time. All requirements placed on UTC flow backwards from here. You can't just edit UTC (or GMT) out of the debate. What common international vision of time? There is no common international LCT. stage one is atomic time (e.g., TAI) stage two is international civil time (e.g., UTC) stage three is local legal time (e.g., Mountain Standard Time) What we are looking for is to redefine stage three directly in terms of stage one without regard to a factitious stage two. 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. Exactly! That is what the principle of subsidiarity demands, and it is a situation we already know how to handle. A fall back event means that the clock (local, standard, international, whatever clock you want) first traverses an hour - and then traverses it again. Under the current three stage system it is only the most local stage three clocks that are affected. You are, in effect, promoting this discontinuity to stage two - to the worldwide business timescale. More to the point, you have said that stage one can be mapped back-and-forth to stage two. But we've just shown that this is no longer a one-to-one mapping since the hour is traversed twice, corresponding to two hours of TAI duration. You've redefined stage two in the course of this discussion. Before it meant LCT, now it means UTC. But be that as it may. Since we (PHK and I) are in favor of abolishing stage two, we are not promoting the discontinuity from stage three to stage two. Rather, we are interested in allowing the various local authorities to introduce changes into their stage three clocks *as they decide* to deal with any perceived problems. The true leap hour folks, if any, are actually doing what you say we are doing: creating a large discontinuity in stage two. The fake leap hour folks, if any, are actually doing what we want, but are cynically saying there will be a leap hour in stage two while not expecting such a thing to ever happen. Ah! But you've suggested that the other half of the annual daylight saving pendulum be used. This doesn't work because we're on the wrong side of the pendulum's arc. The point being that you don't need to *not* adjust the clock in the Autumn - you need to not adjust the clock in the Spring. It is the springtime gap in the mapping (also not a very desirable feature for a time scale) that is omitted during one of these events - not the harvest-time doubly traversed hour. Fair enough. (We'll omit discussion of the fact that not all localities observe daylight saving time in the first place.) By all means. (This is the rhetorical figure of *praeteritio*.) This is the same point I was trying to make about the 25 hour day. No historian or lawyer is going to look favorably on a situation that results in ambiguous timestamps. Perhaps, you say, such timestamps should all be kept in TAI. But in that case, we are back to the original question of why a stage two clock is needed at all. By asserting stage two is needed, all the rest logically follows. And we assert that stage two is *not* needed. In any case, most of the world's population deals with ambiguous timestamps every year. 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. This turns out not to be a big problem, except for the makers of calendar programs. -- John Cowan http://www.ccil.org/~cowan [EMAIL PROTECTED] Be yourself.
Re: interoperability
Poul-Henning Kamp scripsit: Windows have got it right now I belive, but it used to be that a file created and transmitted from Denmark at the end of the business day would be older than a file created at the start of business day in California, despite a strict ordering of the events. It's still true in the sense that the hardware clock is assumed to run in LCT on Windows, and therefore discovering UTC depends on a correctly set TZ variable. It's false in the sense that Windows now supports TZ correctly. Sure, and you can timestamp then on either timescale, because there is a 1 to 1 translation between the two timescales [1]. I think it's confusing to call it 1 to 1, except in the sense that LCT seconds are the same length as UTC/TAI seconds. There are many LCT timestamps that correspond to more than one UTC timestamp. This can be kludged around by adding a bit (the isdst field in a struct time) to say whether a LCT timestamp is the first or the second instance. The scheme you propose is eminently workable, and more or less exactly what we advocate. I'm happy that you now see the merits of it. Nope, he still doesn't. -- On the Semantic Web, it's too hard to prove John Cowan[EMAIL PROTECTED] you're not a dog. --Bill de hOra http://www.ccil.org/~cowan
Re: interoperability
In message [EMAIL PROTECTED], Rob Seaman writes: As I pointed out close to five years ago, the ultimate long term remediation will likely involve redefining the length of the second: Rob, I think this shows how little you understand of the entire thing. 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. To cut this part of the topic out in cardboard for you: 1. The Earths rotation and to a lesser degree its orbital motion are lousy timekeeping devices, many orders of magnitude worse than the best atomic frequency normals. 2. In metrology you use the best available method to implement a fundamental unit. But there is something else which bugs me. Throughout all of these interminable discussions it has become clear to me that you argue backwards from the end (there must be a UTC with leapseconds) rather than forward from the beginning (SI seconds are constant lengt). In our most recent little exchange, you started out proposing a two (or three) timescale solution without leap seconds, and then when I showed that it worked out just the way we wanted, you started to redefine the timescales so that one of them had to be UTC with leapseconds. You also keep harping about how day and night will switch places without leapseconds, while at the same time dismissing the governmentally defined local timezones as irrelevant, despite the fact that they do the heavy lifting (four orders of magnitude more than leapseconds) of holding the sun high in the sky at noon. In other words, you are not arguing in good fait and behave more like a religious zealot than anything else. That is deeply unserious behaviour of a scientist Rob. 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: interoperability
On Jan 9, 2006, at 12:03 AM, John Cowan wrote: Each locality decides when and how to adjust both its offset from TAI and its seasonal transition function (if any), just as it does today. Not just as today, see intervening messages. What we abandon is a universal time tightly synchronized to Earth rotation in favor of a universal time independent of earth rotation plus 400+ local civil times Perhaps some neutral party would like to officiate? Three questions: 1) Could this ever possibly work? (Please point out where my earlier dissection fails.) 2) For the sake of argument, imagine it could work. Would it be an improvement? 3) It suffers the same quadratic meltdown. Why change?
Re: interoperability
In message: [EMAIL PROTECTED] John Cowan [EMAIL PROTECTED] writes: : But how in practice is it envisaged that a scheme : for migrating time zones versus TAI would work, precisely? : : Straightforwardly. Each locality decides when and how to adjust both : its offset from TAI and its seasonal transition function (if any), : just as it does today. What we abandon is a universal time tightly : synchronized to Earth rotation in favor of a universal time : independent of earth rotation plus 400+ local civil times roughly : synchronized to Earth rotation containing various glitches. No matter what we do with leapseconds, there are still all those time zones. The problem with stopping leap seconds altogether is that the legal definitions of time, although quite varied, are all about the same as UTC as it exists today. They are close enough that most countries have adopted UTC bureaucratically rather than legislatively. The official time for the US, as published by the folks at NIST, is UTC. The US law says mean solar time, as determined by the Secretary of Commerce, who has delegated it to the Time and Frequency division of NIST, who in turn use UTC. NIST could easily use a different schedule for leap second insertion (it could have inserted the leap second in civilian time at the end of any day it wanted to and still maintained the mean solar time legal requirement). However, since UTC is a recognized, international standard, the US went along and did its leap second according to that standard. This is a explicit choice that someone, somewhere had to make, even though it is arguably the best choice to make (wouldn't want to be the odd man out in civil time, think of the impact on business). The combination of UTC approximating the legal time is so man nations, as well as the need for international consensus among lots of parties with divergent views for any changes to the current system is why we'll likely not see significant changes any time soon. The best we can hope for is that something will be done to change their unpredictable nature given that we have good forcasting tools at our disposal. Warner
Re: interoperability
On Sun, 8 Jan 2006, Tom Van Baak wrote: between astronomical and atomic timescales. Could we rephrase that between geophysical and atomic timescales ? Astronomers measure it and have to compensate for it, not cause it. Reminds me bitterly of the widely reported loss of Mars Climate Orbiter being due to a confusion of metric and *english* units, like it was our fault. Pete.
