Re: [LEAPSECS] Seems relevant somehow
Steve Allen wrote at 22:35 -0700 on Mar 30, 2008: Someone please tell me again why the zoneinfo files would need 10 years of advance notice if they were to absorb responsibility for leap seconds. There are a wide variety of applications that don't care about local time. If some politicians decide to change DST rules, these applications couldn't care less. For those applications that do care about local time, there are other forums for discussing this class of problem. It's certainly a real issue for some, but is separable from the issues associated with leap seconds. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
[LEAPSECS] the inescapability of feedback
Steve Allen wrote: Someone please tell me again why the zoneinfo files would need 10 years of advance notice if they were to absorb responsibility for leap seconds. Rather the opposite. Nobody would object if the schedule for announcing leapseconds could be extended to 10 years (all else being equal). On the other hand, world governments would balk at any attempt to limit their sovereignty by requiring a 10 year lag before timezone and DST changes could take effect. The scientific community is clearly more accommodating here than the political community. A parable: NOAO has facilities in southern Arizona and northern Chile. Neither Chile nor Arizona underwent a daylight saving time change on March 9, and yet both encountered DST goofs on that day. Arizona doesn't observe DST (the last thing we need to save is daylight), and the government of Chile decided to extend DST for the southern summer for a few extra weeks this year. Several atomic wall clocks reset themselves in Arizona. They actually fell back, rather than forward (?!?) - best guess is that they had been set to Pacific time + DST and the DST flag was interpreted as a toggle (thus shifting to standard time). Sounds pretty lame, but that's what the clocks did. A large number of NTP synced unix clocks (various flavors) in Chile automatically moved back to standard time since the configurations weren't updated in a timely fashion. One would expect the stress of rising energy prices combined with the rather contradictory logic of DST regarding saving energy to only result in additional short notice government timekeeping decisions. This suggests that there is a requirement for an improved infrastructure for managing timezone information, and not to allow the infrastructure to wither. The only alternative is chaos. Poul-Henning Kamp wrote: Because stupid handling of timezones is something politicians you vote for do, and consequently there is a feedback loop that can discourage such behaviour. Leapseconds are mandated by a bunch of scientists who are not accountable for anybody if they suddenly decide to issue leapseconds with 1 month notice. It is a neat trick to accuse one party (scientists) with the crime of the other (politicians). Scientists are much more accountable through funding agencies, etc., than any government entity. Note also, of course, that not all stakeholders have the opportunity to vote for their politicians. And what is the ITU but a mechanism for holding a bunch of scientists accountable? With absolutely zero irony, this mailing list can be described as such a feedback mechanism. The ultimate feedback loops for timekeeping are the natural rhythms that govern our civil institutions and technical infrastructure. We (scientists or politicians) are not free to willy-nilly redefine the clock and the calendar. In particular, the clock is a subdivision of the calendar. The ITU initiative refers to leap seconds, but it is really an attempt to change the definition of the day. I've gotta say that I'm perplexed at your reception of Steve's suggestion. Your own idea (correct me if I'm wrong) is that the secular clock drift due to embargoed leap seconds will be accommodated via local adjustments to the standard timezone system. Steve has simply fleshed out the details for one such mechanism to manage all the local adjustments coherently. If leap seconds aren't going to carry the weight of civil time anymore, than this weight will fall somewhere else. If it falls onto the system of timezones, then the timezones will have to be reinforced to bear the weight. If not via zoneinfo, then how? John Hein wrote: For those applications that do care about local time, there are other forums for discussing this class of problem. It's certainly a real issue for some, but is separable from the issues associated with leap seconds. It is precisely that UTC is kept stationary with respect to mean solar time that permits local timezone issues like DST to be separable from UTC as you describe. Rob Seaman National Optical Astronomy Observatory ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] operational time -- What's in a name?
On Fri, 28 Mar 2008, Steve Allen wrote: Part of the beauty of distinguishing broadcast time signals from UTC, while continuing both, is that it allows separate issues to be addressed separately. I allow that the broadcast time signals should be leap free, for there are many operational systems which will benefit from that simplicity. From many quarters it seems that is a really big issue. If we change the name of the broadcast signals then they can go leap free on a very short time scale. Right after the next leap second would likely be a really good time. So you think that the millions of existing radio controlled clocks and watches should stop showing civil time? Tony (wondering why his MSF clock failed to switch to BST). -- f.anthony.n.finch [EMAIL PROTECTED] http://dotat.at/ IRISH SEA: VARIABLE 4 BECOMING SOUTH OR SOUTHWEST 5 TO 7, PERHAPS GALE 8 LATER. MODERATE OR ROUGH. SHOWERS THEN RAIN. MODERATE, OCCASIONALLY POOR. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] operational time -- What's in a name?
Tony Finch said: So you think that the millions of existing radio controlled clocks and watches should stop showing civil time? They already do. Tony (wondering why his MSF clock failed to switch to BST). Mine changed fine, though it was a bit moot since the entire family was in Italy until about 6 hours before. But MSF reports UTC, not civil time (GMT). -- 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|| ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] operational time -- What's in a name?
On Mon 2008-03-31T12:20:06 +0100, Tony Finch hath writ: So you think that the millions of existing radio controlled clocks and watches should stop showing civil time? Yes, that is, yes to a subsecond precision. They would be showing TI instead of UT, another international standard, and a difference which (to replay the words of the folks who would abolish leap seconds) would amount to less than two minutes by the end of the century. I expect that Casio, Timex, and the other radio-controlled walk clock and wristwatch manufacturers would cry all the way to the bank as people bought new ones when the difference in seconds became notable to those who care that much. And for the rest, most of those timepieces would have disintegrated from their poor construction prior to the time when the difference between TI and UTC was larger than a non-radio-controlled timepiece. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the inescapability of feedback
Rob Seaman wrote at 00:55 -0700 on Mar 31, 2008: John Hein wrote: For those applications that do care about local time, there are other forums for discussing this class of problem. It's certainly a real issue for some, but is separable from the issues associated with leap seconds. It is precisely that UTC is kept stationary with respect to mean solar time that permits local timezone issues like DST to be separable from UTC as you describe. The issues are separable for more pragmatic reasons than that, or at least that's the effect I was describing. If UTC no longer has leap seconds or the computers use Steve's TI or similar, and time zones gradually drift around the earth over the centuries relative to that timescale, the issues will still be practically separable. The class of applications that don't care about local time still won't. The class of applications that do care about local time still will have the same problems to contend with. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] operational time -- What's in a name?
Rob Seaman said: Ease of setting is a great feature. But setting a clock also involves checking that you set it correctly (selected the right combination of buttons on the back). Um, what buttons on the back? My kitchen RC clock has none such (probably because just about all of the UK is in the same time zone). -- 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|| ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the inescapability of feedback
On Mon 2008-03-31T00:55:55 -0700, Rob Seaman hath writ: It is a neat trick to accuse one party (scientists) with the crime of the other (politicians). I will stipulate that both the ITU-R and the IAU are guilty of politics, and move on. There is a stark difference in the written record between the actions of the CCIR/ITU-R and the IAU. The CCIR/ITU-R processes hold meetings of working groups which produce documents that are not broadly published and sometimes result in changes by fiat, within a span of a single Plenipotentiary Cycle, which have side effects which are not always addressed in advance. The IAU processes usually stretch over decades with a series of conferences that produce openly published literature treating every side effect anyone can think of. On Mon 2008-03-31T08:06:54 -0600, John E Hein hath writ: If UTC no longer has leap seconds or the computers use Steve's TI or similar International Time, Temps International, TI is not my invention. I was not at the Colloquium on UTC that the ITU-R WP7A held in Torino in 2003. TI is the result that was produced at the end of that meeting. See page 3 of the closure/conclusion produced by Ron Beard http://www.ien.it/luc/cesio/itu/closure.pdf The ITU-R called for international experts to come and provide advice, and the advice was to change the name. -- Steve Allen [EMAIL PROTECTED]WGS-84 (GPS) UCO/Lick ObservatoryNatural Sciences II, Room 165Lat +36.99855 University of CaliforniaVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
Re: [LEAPSECS] the inescapability of feedback
Steve Allen wrote at 18:56 -0700 on Mar 31, 2008: On Mon 2008-03-31T08:06:54 -0600, John E Hein hath writ: If UTC no longer has leap seconds or the computers use Steve's TI or similar International Time, Temps International, TI is not my invention. I was not at the Colloquium on UTC that the ITU-R WP7A held in Torino in 2003. TI is the result that was produced at the end of that meeting. See page 3 of the closure/conclusion produced by Ron Beard http://www.ien.it/luc/cesio/itu/closure.pdf The ITU-R called for international experts to come and provide advice, and the advice was to change the name. Sorry to imply that Steve invented it. He put it forward as a time_t replacement in his Feb 9 zoneinfo proposal. ___ LEAPSECS mailing list LEAPSECS@leapsecond.com http://six.pairlist.net/mailman/listinfo/leapsecs
