From seaman at noao.edu Mon Mar 3 13:47:30 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 3 Mar 2008 11:47:30 -0700 Subject: [LEAPSECS] timekeeping requirements Message-ID: Something different to discuss regarding real-world timekeeping requirements. - Rob -- Al-Chaahad: new concept for young moon sighting verification Paper 7017-49 Author(s): Mohamed Laoucet Ayari, Univ. of Colorado/Boulder Hide Abstract With an estimated two billion people worldwide dependent upon new moon sightings to establish the timeline of lunar months and festivals, there has long remained controversy regarding the verification of naked eye visibility of the new moon. At no time in history have the technological pieces so readily aligned to solve this problem as the present. Al-Chaahad is a system which provides the first serious opportunity to unify new moon sightings, and consolidate the sighting process in a verifiable and reliable framework. Over the past 30 months, field tests have assisted in the development of a scalable system that enables anyone located anywhere in the world to utilize the combined power of proven technologies including elements of orbital mechanics, imaging, global positioning system, atomic clock reading, secure communication and image processing to document sightings. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seaman at noao.edu Mon Mar 3 14:02:08 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 3 Mar 2008 12:02:08 -0700 Subject: [LEAPSECS] timekeeping requirements In-Reply-To: References: Message-ID: I neglected to mention that this is from an SPIE program: http://spie.org/app/program/index.cfm?fuseaction=conferencedetail&export_id=x13724&ID=x13667&redir=x13667.xml&conference_id=796763&event_id=796182&programtrack_id=796772 -- On Mar 3, 2008, at 11:47 AM, Rob Seaman wrote: > Something different to discuss regarding real-world timekeeping > requirements. - Rob > -- > > > Al-Chaahad: new concept for young moon sighting verification > > Paper 7017-49 > Author(s): Mohamed Laoucet Ayari, Univ. of Colorado/Boulder > Hide Abstract > With an estimated two billion people worldwide dependent upon new > moon sightings to establish the timeline of lunar months and > festivals, there has long remained controversy regarding the > verification of naked eye visibility of the new moon. At no time in > history have the technological pieces so readily aligned to solve > this problem as the present. Al-Chaahad is a system which provides > the first serious opportunity to unify new moon sightings, and > consolidate the sighting process in a verifiable and reliable > framework. Over the past 30 months, field tests have assisted in the > development of a scalable system that enables anyone located > anywhere in the world to utilize the combined power of proven > technologies including elements of orbital mechanics, imaging, > global positioning system, atomic clock reading, secure > communication and image processing to document sightings. > > > _______________________________________________ > LEAPSECS mailing list > LEAPSECS at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs -------------- next part -------------- An HTML attachment was scrubbed... URL: From sla at ucolick.org Mon Mar 3 14:15:36 2008 From: sla at ucolick.org (Steve Allen) Date: Mon, 3 Mar 2008 11:15:36 -0800 Subject: [LEAPSECS] timekeeping requirements In-Reply-To: References: Message-ID: <20080303191536.GA21883@ucolick.org> On Mon 2008-03-03T11:47:30 -0700, Rob Seaman hath writ: > Something different to discuss regarding real-world timekeeping > requirements. - Rob >> With an estimated two billion people worldwide dependent upon new moon >> sightings to establish the timeline of lunar months and festivals, My expectation that Allah will strike me down for failing to celebrate Ramadan on the right day is about equally unmotivating as the notion that a leap second will cause planes to fall out of the sky. I expect both systems to be forgiving of a little bit of slop in the implementation. I allow that there are valid reasons for pursuing research into visibility of the hilal and monotonic time scales for telecomms, navigation, etc., but I don't see that either of these justify modifications to the characteristics of civil time. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From mgy1912 at cox.net Mon Mar 3 14:49:49 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 3 Mar 2008 11:49:49 -0800 Subject: [LEAPSECS] timekeeping requirements References: <20080303191536.GA21883@ucolick.org> Message-ID: <000801c87d67$bd653850$9187db48@Fnord> ----- Original Message ----- From: "Steve Allen" To: "Leap Second Discussion List" Sent: Monday, March 03, 2008 11:15 AM Subject: Re: [LEAPSECS] timekeeping requirements > On Mon 2008-03-03T11:47:30 -0700, Rob Seaman hath writ: >> Something different to discuss regarding real-world timekeeping >> requirements. - Rob > >>> With an estimated two billion people worldwide dependent upon new moon >>> sightings to establish the timeline of lunar months and festivals, > > My expectation that Allah will strike me down for failing to celebrate > Ramadan on the right day is about equally unmotivating as the notion > that a leap second will cause planes to fall out of the sky. I expect > both systems to be forgiving of a little bit of slop in the > implementation. > Islam has provisions for not being able to see the hilal due to cloudy weather, or being uncertain as to the moon's visibility on the day Ramadan is supposed to start. You simply count 30 days from whenever the preceding month (Shawwal) began, and start your fast on the following day. Given that these same 2 billion people who are "dependent" on naked-eye sighting of the full moon already have to deal with one or two days' uncertainty in the exact moment of visibility--not to mention the fact that the International Date Line already prevents all the world's Muslims from starting their observances on the same calendar day--I fail to see how precise atomic timekeeping helps them out that much. DUT1 can't possibly be a factor for a timekeeping system intentionally designed to avoid the need for advanced observation methods. Brian Garrett From seaman at noao.edu Mon Mar 3 16:41:37 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 3 Mar 2008 14:41:37 -0700 Subject: [LEAPSECS] timekeeping requirements In-Reply-To: <000801c87d67$bd653850$9187db48@Fnord> References: <20080303191536.GA21883@ucolick.org> <000801c87d67$bd653850$9187db48@Fnord> Message-ID: Steve Allen wrote: > I expect both systems to be forgiving of a little bit of slop in the > implementation. I would say the system design should be responsive to the requirement for this degree of freedom. "Slop in the implementation" is not only an unhelpful phrasing, it is inaccurate. The implementation should be verified to accurately reflect a valid design. The design should respond to use cases via requirement discovery. The appropriate stakeholders should reach a consensus at the level of the use cases and requirements of the system, not down in the engineering details or deployed functionality. That said, I agree with Steve's position :-) Our systems are required (and have been demonstrated) to be robust in the face of timekeeping interruptions of many sorts. Why are we picking on leap seconds? Brian Garrett wrote: > I fail to see how precise atomic timekeeping helps them out that > much. DUT1 can't possibly be a factor for a timekeeping system > intentionally designed to avoid the need for advanced observation > methods. The deadline for contributions to SPIE proceedings is before the conference. If we disbelieve the necessity for such a system, we could consult the literature rather than speculate. I'm tired of hearing the wide range of systems for which DUT1 can't possibly be a factor. Presumably we'll find out in a few years if we can't be bothered to consider the issue in a professional engineering context in advance of making new policy. Rob Seaman NOAO From mgy1912 at cox.net Mon Mar 3 17:37:23 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 3 Mar 2008 14:37:23 -0800 Subject: [LEAPSECS] timekeeping requirements References: <20080303191536.GA21883@ucolick.org><000801c87d67$bd653850$9187db48@Fnord> Message-ID: <001601c87d7f$260f3ab0$9187db48@Fnord> ----- Original Message ----- From: "Rob Seaman" To: "Leap Second Discussion List" Sent: Monday, March 03, 2008 1:41 PM Subject: Re: [LEAPSECS] timekeeping requirements > Brian Garrett wrote: > >> I fail to see how precise atomic timekeeping helps them out that much. >> DUT1 can't possibly be a factor for a timekeeping system intentionally >> designed to avoid the need for advanced observation methods. > > > The deadline for contributions to SPIE proceedings is before the > conference. If we disbelieve the necessity for such a system, we could > consult the literature rather than speculate. I'm tired of hearing the > wide range of systems for which DUT1 can't possibly be a factor. > Presumably we'll find out in a few years if we can't be bothered to > consider the issue in a professional engineering context in advance of > making new policy. > > Rob Seaman > NOAO In the case of Islamic observances, it would depend on whether you were doing short- or long-term planning. To determine the date of *this* year's Ramadan fast, all you would need to know would be the date on which the new moon could reasonably be expected to be visible, and then verify on the actual day whether or not it was visible. For those Muslims who insist on a strict interpretation of Sharia, this is all that is required. However, countries such as Saudi Arabia who have to plan around annual events like the Hajj require a calendar that is reliable over a year in advance. The dates of observance, reckoned by the Muslim calendar, would depend on the position of the sun and moon, calculation of which is affected by delta-T, which is resolvable to within one second and therefore influenced by DUT1. Somewhat important if you're planning a pilgrimage next year or the year after. Once again, Shaitan is in the details :) Brian Garrett From sla at ucolick.org Tue Mar 4 01:56:32 2008 From: sla at ucolick.org (Steve Allen) Date: Mon, 3 Mar 2008 22:56:32 -0800 Subject: [LEAPSECS] civil time Message-ID: <20080304065632.GA25434@ucolick.org> I gotta thank slashdot for pointing out old news Indiana proves that Daylight Saving Time wastes energy http://online.wsj.com/public/article/SB120406767043794825-UOLcfJA8x9Gw9ozbCz77MiLmtaE_20080327.html?mod=tff_main_tff_top My kinfolk are in Indiana. Hang in there Arizona! -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From seaman at noao.edu Tue Mar 4 02:05:30 2008 From: seaman at noao.edu (Rob Seaman) Date: Tue, 4 Mar 2008 00:05:30 -0700 Subject: [LEAPSECS] timekeeping requirements In-Reply-To: References: <20080303191536.GA21883@ucolick.org><000801c87d67$bd653850$9187db48@Fnord> <001601c87d7f$260f3ab0$9187db48@Fnord> Message-ID: <03CE6E3E-7EF7-4D8F-AF4F-E4E720AE000B@noao.edu> Brian Garrett wrote: > it would depend on whether you were doing short- or long-term > planning. Now there is a distinction I can get behind. > Once again, Shaitan is in the details :) Two for two - you've summed up my entire perspective :-) - Rob From dwmalone at maths.tcd.ie Tue Mar 4 06:59:56 2008 From: dwmalone at maths.tcd.ie (David Malone) Date: Tue, 04 Mar 2008 11:59:56 +0000 Subject: [LEAPSECS] Calendar reform Message-ID: <200803041159.aa56837@walton.maths.tcd.ie> Easter is quite early this year - early enough that St Patrick's day and Good Friday fall in the same week. This is seemingly a suprise for the Irish Hoteliers, and is making their life hard: http://www.examiner.ie/irishexaminer/pages/story.aspx-qqqg=business-qqqm=business-qqqa=business-qqqid=56851-qqqx=1.asp Just wait till they find out that we don't know when the next leap second is! David. From dot at dotat.at Tue Mar 4 08:11:18 2008 From: dot at dotat.at (Tony Finch) Date: Tue, 4 Mar 2008 13:11:18 +0000 Subject: [LEAPSECS] Calendar reform In-Reply-To: <200803041159.aa56837@walton.maths.tcd.ie> References: <200803041159.aa56837@walton.maths.tcd.ie> Message-ID: On Tue, 4 Mar 2008, David Malone wrote: > Easter is quite early this year - early enough that St Patrick's > day and Good Friday fall in the same week. This is seemingly a > suprise for the Irish Hoteliers, and is making their life hard: > > http://www.examiner.ie/irishexaminer/pages/story.aspx-qqqg=business-qqqm=business-qqqa=business-qqqid=56851-qqqx=1.asp For 80 years the UK has had an act on the statute books that says Easter should be the first Sunday after the second Saturday in April. However the act has never been brought into force. http://www.statutelaw.gov.uk/content.aspx?ActiveTextDocId=1080813 Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE FAEROES: NORTHWEST BACKING SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. SHOWERS THEN RAIN. MODERATE OR GOOD, OCCASIONALLY POOR. From seaman at noao.edu Tue Mar 11 22:40:42 2008 From: seaman at noao.edu (Rob Seaman) Date: Tue, 11 Mar 2008 19:40:42 -0700 Subject: [LEAPSECS] The economics of interstellar trade Message-ID: <855F4140-BABF-4113-B34E-573570E940BD@noao.edu> The abstract: This paper extends interplanetary trade theory to an interstellar setting. It is chiefly concerned with the following question: how should interest charges on goods in transit be computed when the goods travel at close to the speed of light? This is a problem because the time taken in transit will appear less to an observer travelling [sic] with the goods than to a stationary observer. A solution is derived from economic theory, and two useless but true theorems are proved. The quote (draw your own conclusions about how this applies to leap seconds): "This paper, then, is a serious analysis of a ridiculous subject, which is of course the opposite of what is usual in economics." The paper: http://www.princeton.edu/~pkrugman/interstellar.pdf Some context: http://www.salon.com/tech/htww/?last_story=/tech/htww/2008/03/11/paul_krugman_in_outer_space Figure II takes Edward Tufte's admonition to minimize non-data ink to its logical conclusion. From sla at ucolick.org Fri Mar 21 03:21:24 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 21 Mar 2008 00:21:24 -0700 Subject: [LEAPSECS] double leap seconds, they almost were real Message-ID: <20080321072124.GA12952@ucolick.org> I submit the following images from the proceedings of the plenary assembly of the CCIR in New Delhi in 1970. First is the report of the working groups who decided to abandon UT2 and switch to leap seconds, including a summary of the original draft form of CCIR Rec 460. http://www.ucolick.org/~sla/leapsecs/CCIR1970v7p182.png The notes from the 13th session on 1970-02-03 indicate that the recommendation was approved with deletion of the words "or integral multiples thereof" so that the initial form of the recommendation as adopted was http://www.ucolick.org/~sla/leapsecs/CCIR1970v3p227R460.png Wherein point 4 indicates that they had not yet figured out exactly how the scheme was going to work. Point 6 requested that the document be transmitted to, among other places, the IAU, and the CCIR failed to perform that action. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Tue Mar 25 10:30:05 2008 From: sla at ucolick.org (Steve Allen) Date: Tue, 25 Mar 2008 07:30:05 -0700 Subject: [LEAPSECS] WP7A Message-ID: <20080325143005.GA25856@ucolick.org> It's less than a week until WP7A meets, and the list of contributions regarding UTC looks interesting http://www.itu.int/md/R07-WP7A-C/en France is in there twice! -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Fri Mar 28 00:12:49 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 27 Mar 2008 21:12:49 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080211184032.GA21325@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> Message-ID: <20080328041249.GA20110@ucolick.org> On Mon 2008-02-11T10:40:32 -0800, Steve Allen hath writ: > On Mon 2008-02-11T13:31:17 +0000, Tony Finch hath writ: > > Surely its work on the ITRF is still needed for satellite navigation. > > Agreed, but somehow I get the impression that will not catch the > attention of legislators and bureaucrats nearly as well as pointing > out that their earth rotation measurements directly affect how they > set their watches. I expect the IERS would lose a lot of visibility > and political clout without leap seconds. Upon further consideration, I'm not sure I agree. For the purposes of satellite navigation there is not need for the terrestrial reference frame to be tightly tied to the celestial reference frame. Achieving accuracy of 1 meter certainly doesn't care about rapid changes of earth orientation parameters with respect to the quasars, only with respect to the satellites. So it could be argued that the need for VLBI campaigns would become a scientific extravagance no longer relevant to civil life. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Fri Mar 28 00:15:05 2008 From: sla at ucolick.org (Steve Allen) Date: Thu, 27 Mar 2008 21:15:05 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <27896.1203027419@critter.freebsd.dk> References: <20080214221022.GA20007@ucolick.org> <27896.1203027419@critter.freebsd.dk> Message-ID: <20080328041505.GA20152@ucolick.org> On Thu 2008-02-14T22:16:59 +0000, Poul-Henning Kamp hath writ: > In message <20080214221022.GA20007 at ucolick.org>, Steve Allen writes: > >That's what they said about changing the conventional longitudes of > >every observatory on the planet in order to get agreement on the value > >of UT starting in 1962. But in 1961 the IAU said "do it", and they > >did -- even in cases where it caused a time step in the sovereign time > >scale of a nation, and even where it introduced a new, potentially > >ambiguous notion of origin of longitude for civil mapping. > > This comparison is so bogus that we ought to frame and hang it. > > In 1961, the task was on a few handfulls of scientific people, most, > if not all, of them phd's, and all of them very much at home in the > subject domain. > > Fiddling with time_t today would involves more than a million > persons, very few of which can readily tell you what a leap-second is. I disagree. All of the technical part falls into the hands of the folks who maintain the zoneinfo files and their code equivalents (including other, non-POSIX systems for timezone offsets). The actual number of people who have to know what they are doing is probably comensurable with the number of people in the time bureaus in 1962. The rest of those million people need merely install a zoneinfo and code update as they do every time any jurisdiction decides to change the dates of its daylight time transition. So again, the notion is this: That the ITU-R follow the recommendations that were produced at their own colloquium in Torino (instead of letting their spokespersons misrepresent that meeting saying that it did not call for a new name. There are precedents for choosing a new name, look here http://adsabs.harvard.edu/cgi-bin/nph-bib_query?bibcode=1978QJRAS..19..290S to see a description of the confusion caused by the Royal Navy's Admiralty.) That the ITU-R adopt a leap free broadcast timescale with the new name something like International Time (TI) to be defined much more simply than the current UTC as TAI minus however many leap seconds have effectively been inserted since 1958-01-01. That the ITU-R relinquish UTC to BIPM and IERS, allowing them to deal with the civil time issues of leap seconds while the ITU-R focusses solely on the technical issues of systems that need uniform time. That POSIX time_t henceforth be interpreted as TI, and that the leap seconds go into the zoneinfo files such that most time zones, including UTC, start being a number of hours minus leap seconds off from TI. And the consequence of any of those million people not doing the update is minimal. After the first leap second their clock is off by only 1 second, and their clock is still tracking an international standard, now TI instead of UTC. This is merely a name change from one standard to another. It's akin to what happened in the US on 1966-12-01T00:00 when WWV moved from Maryland to Colorado and changed from broadcasting Eastern Standard Time to Mountain Standard Time. It's akin to what happened in the US on 1967-04-28T21:00 when the announcments from WWV and WWVH changed from saying Mountain Standard Time and Hawaii Standard Time to GMT. It's akin to what happened in the US on 1974-01-01 when WWV and WWVH changed from announcing GMT to UTC -- yes, that's right, UTC didn't really start in the US until two years after leap seconds. The trick with the change of time worldwide in 1962 and 1972, and in the US in 1966, 1967, and 1974, was to preserve the characteristics of the *operational* systems. These changes in conventional longitudes, and in name of the time scale, did not have any effect on operational systems. Even if those million people wait until the end of the century the difference between the TI-based time and UTC-based time is only a minute or so. And here I note that the same argument raised by the folks who want to abandon leaps in UTC applies the other direction, too: If it is of little consequence for most clocks to be off from the sun by a minute or so, then it is of little consequence for most clocks to be using one international time standard or another that differ by a a few seconds. I can't predict traffic congestion well enough to arrive at work within a given minute, let alone a second, and that's most of the purpose of civil time. The operational systems won't care about the name of the system they're using, and most every other system where the difference of consequence will get upgraded to use a new scheme before the difference is more than a few seconds. We have the ability to do this either way. What we have to decide is whether we will abandon the notion that clock and calendar are related. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From seaman at noao.edu Fri Mar 28 03:09:50 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 00:09:50 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080328041249.GA20110@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> <20080328041249.GA20110@ucolick.org> Message-ID: <17AD2403-ED64-4F54-9363-2C4D3653C7EF@noao.edu> Steve Allen wrote: > For the purposes of satellite navigation there is not need for the > terrestrial reference frame to be tightly tied to the celestial > reference frame. Achieving accuracy of 1 meter certainly doesn't > care about rapid changes of earth orientation parameters with > respect to the quasars, only with respect to the satellites. So it > could be argued that the need for VLBI campaigns would become a > scientific extravagance no longer relevant to civil life. With the passing of Arthur C. Clarke (inventor of the geosynchronous satellite, of course), I'm reminded here of his "City and the Stars" (reworked from "Against the Fall of Night"). Billion year old Diaspar (talk about sustainable technology!). Lonely city on a lonely (mostly) planet in a lonely galaxy. Incarnation by mainframe. (I suppose if you only have one computer, timekeeping is simplified :-) We can retreat from the universe. Clarke, for one, was confident that the universe won't (ultimately) retreat from us. Extravagance is what makes civil life relevant. Rob Seaman National Optical Astronomy Observatory From phk at phk.freebsd.dk Fri Mar 28 07:42:25 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 11:42:25 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Thu, 27 Mar 2008 21:15:05 MST." <20080328041505.GA20152@ucolick.org> Message-ID: <4353.1206704545@critter.freebsd.dk> In message <20080328041505.GA20152 at ucolick.org>, Steve Allen writes: >> In 1961, the task was on a few handfulls of scientific people, most, >> if not all, of them phd's, and all of them very much at home in the >> subject domain. >> >> Fiddling with time_t today would involves more than a million >> persons, very few of which can readily tell you what a leap-second is. > >I disagree. All of the technical part falls into the hands of the >folks who maintain the zoneinfo files and their code equivalents >(including other, non-POSIX systems for timezone offsets). No, that is only the part where time_t gets converted to local time. All the code that assume that time_t is UTC will get burned, and trust me: that is far more code than you imagine. >The rest of those million people need merely install a zoneinfo and >code update as they do every time any jurisdiction decides to change >the dates of its daylight time transition. Simply not true. A good place to start is the FreeBSD ports-tree which contains about 18000 piece of open source software. Try to change time_t to a non-arithmetic type and see how far you get. >That POSIX time_t henceforth be interpreted as TI, and that the leap >seconds go into the zoneinfo files such that most time zones, >including UTC, start being a number of hours minus leap seconds off >from TI. This is exactly the flagday that will make the upgrades to a few hundered telescopes look like peanuts. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From dot at dotat.at Fri Mar 28 07:43:23 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 28 Mar 2008 11:43:23 +0000 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080328041249.GA20110@ucolick.org> References: <20080210043602.GA14616@ucolick.org> <20080211184032.GA21325@ucolick.org> <20080328041249.GA20110@ucolick.org> Message-ID: On Thu, 27 Mar 2008, Steve Allen wrote: > > Upon further consideration, I'm not sure I agree. For the purposes of > satellite navigation there is not need for the terrestrial reference > frame to be tightly tied to the celestial reference frame. Achieving > accuracy of 1 meter certainly doesn't care about rapid changes of > earth orientation parameters with respect to the quasars, only with > respect to the satellites. So it could be argued that the need for > VLBI campaigns would become a scientific extravagance no longer > relevant to civil life. Is there enough coupling between Earth rotation and the orbiting satellites to make a difference between their reference frame and one derived from quasars? Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON: WESTERLY BACKING SOUTHERLY 6 TO GALE 8, PERHAPS SEVERE GALE 9 LATER. HIGH. SQUALLY SHOWERS. MODERATE OR POOR. From imp at bsdimp.com Fri Mar 28 08:22:54 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri, 28 Mar 2008 06:22:54 -0600 (MDT) Subject: [LEAPSECS] a modest proposal In-Reply-To: References: <20080211184032.GA21325@ucolick.org> <20080328041249.GA20110@ucolick.org> Message-ID: <20080328.062254.-432840016.imp@bsdimp.com> In message: Tony Finch writes: : On Thu, 27 Mar 2008, Steve Allen wrote: : > : > Upon further consideration, I'm not sure I agree. For the purposes of : > satellite navigation there is not need for the terrestrial reference : > frame to be tightly tied to the celestial reference frame. Achieving : > accuracy of 1 meter certainly doesn't care about rapid changes of : > earth orientation parameters with respect to the quasars, only with : > respect to the satellites. So it could be argued that the need for : > VLBI campaigns would become a scientific extravagance no longer : > relevant to civil life. : : Is there enough coupling between Earth rotation and the orbiting : satellites to make a difference between their reference frame and one : derived from quasars? I don't think so. Leapseconds are a an evil. If they are a good evil, it comes at a high price. Evilness to keep DUT1 < 1s is all in the eyes of the bolder. As someone who has been ill-treated by leapseconds, I fail to see why they are necessary in a society that accepts > 1hr deviation from solar mean time... Sure, they help keep us in sync with the celestial motions, but at what price? Warner From imp at bsdimp.com Fri Mar 28 08:28:27 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri, 28 Mar 2008 06:28:27 -0600 (MDT) Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <4353.1206704545@critter.freebsd.dk> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> Message-ID: <20080328.062827.-957833510.imp@bsdimp.com> In message: <4353.1206704545 at critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20080328041505.GA20152 at ucolick.org>, Steve Allen writes: : : >> In 1961, the task was on a few handfulls of scientific people, most, : >> if not all, of them phd's, and all of them very much at home in the : >> subject domain. : >> : >> Fiddling with time_t today would involves more than a million : >> persons, very few of which can readily tell you what a leap-second is. : > : >I disagree. All of the technical part falls into the hands of the : >folks who maintain the zoneinfo files and their code equivalents : >(including other, non-POSIX systems for timezone offsets). : : No, that is only the part where time_t gets converted to local time. : : All the code that assume that time_t is UTC will get burned, and : trust me: that is far more code than you imagine.n : : >The rest of those million people need merely install a zoneinfo and : >code update as they do every time any jurisdiction decides to change : >the dates of its daylight time transition. : : Simply not true. A good place to start is the FreeBSD ports-tree : which contains about 18000 piece of open source software. : : Try to change time_t to a non-arithmetic type and see how far you : get. although naive math is, well, naive, more code exists that assumes, for example, that midnight it time_t % 86400 == 0 than you want to believe. Changing this is really bad karma. : >That POSIX time_t henceforth be interpreted as TI, and that the leap : >seconds go into the zoneinfo files such that most time zones, : >including UTC, start being a number of hours minus leap seconds off : >from TI. : : This is exactly the flagday that will make the upgrades to a few : hundered telescopes look like peanuts. Fuck the telescopes software. it is order of magnitudes less common than anything else as to be irrelevant than things like ntp. Leap seconds are evil and must die. Society can with stand almost two hour of deviation from solar time. Why does even a leam minute mean anything to 99% of the population. Warner From greg.hennessy at cox.net Fri Mar 28 09:01:01 2008 From: greg.hennessy at cox.net (Greg Hennessy) Date: Fri, 28 Mar 2008 09:01:01 -0400 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328.062827.-957833510.imp@bsdimp.com> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> Message-ID: <47ECEC0D.6030405@cox.net> > although naive math is, well, naive, more code exists that assumes, > for example, that midnight it time_t % 86400 == 0 than you want to > believe. Changing this is really bad karma. The current situation is that code like your example does not accurately reflect reality. I advocate changing the code. You advocate changing reality. > Fuck the telescopes software. it is order of magnitudes less common > than anything else as to be irrelevant than things like ntp. Attitudes like fuck certain people's software don't seem useful to me. > Leap seconds are evil and must die. That is an opinion that not everyone shares. From sla at ucolick.org Fri Mar 28 11:19:05 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 08:19:05 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <4353.1206704545@critter.freebsd.dk> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> Message-ID: <20080328151905.GA25223@ucolick.org> On Fri 2008-03-28T11:42:25 +0000, Poul-Henning Kamp hath writ: > Simply not true. A good place to start is the FreeBSD ports-tree > which contains about 18000 piece of open source software. Is there a detailed inventory of how many of those break in 2038? And how many break as binaries vs. how many would work if recompiled? If the ITU-R cannot find a unilateral stance then it may be time to start thinking compromise. Is getting the leaps out of the system's time_t worth the other hassle? -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From dot at dotat.at Fri Mar 28 11:28:53 2008 From: dot at dotat.at (Tony Finch) Date: Fri, 28 Mar 2008 15:28:53 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <47ECEC0D.6030405@cox.net> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <47ECEC0D.6030405@cox.net> Message-ID: On Fri, 28 Mar 2008, Greg Hennessy wrote: > > > although naive math is, well, naive, more code exists that assumes, > > for example, that midnight it time_t % 86400 == 0 than you want to > > believe. Changing this is really bad karma. > > The current situation is that code like your example does not accurately > reflect reality. The POSIX standard guarantees that what Warner wrote is correct. Tony. -- f.anthony.n.finch http://dotat.at/ FAIR ISLE: SOUTHEAST VEERING SOUTHWEST 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD. From sla at ucolick.org Fri Mar 28 11:33:41 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 08:33:41 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <47ECEC0D.6030405@cox.net> Message-ID: <20080328153341.GA25300@ucolick.org> On Fri 2008-03-28T15:28:53 +0000, Tony Finch hath writ: > The POSIX standard guarantees that what Warner wrote is correct. The POSIX standard is in denial about leap seconds with respect to UTC. I don't know about international standards, but in people I'm sure that's not a good sign, and I try to avoid such. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Fri Mar 28 12:04:09 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 09:04:09 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328.062827.-957833510.imp@bsdimp.com> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> Message-ID: <20080328160409.GA25374@ucolick.org> On Fri 2008-03-28T06:28:27 -0600, M. Warner Losh hath writ: > although naive math is, well, naive, more code exists that assumes, > for example, that midnight it time_t % 86400 == 0 than you want to > believe. Changing this is really bad karma. Except that the current POSIX standard is also bad karma. It asserts that leap seconds do not exist in what it calls UTC. And the ITU-R's UTC does have leap seconds. Both of these things cannot be true, and it is my assertion that the one which is wrong is POSIX. The thing currently stored in POSIX time_t is not UTC. It is a "proliferated" time scale of dubious accuracy and inconsistent implementation. It is a mis-named fantasy. It is exactly what the Time Lords who started this whole thing in 1999 have repeatedly said they want to make go away. But if we call POSIX time_t by a new name (say TI) which has international status and properties which match the specified characteristics of time_t then what we have is enlightenment. We have learned something as a civilization. We have realized that our cognition was incomplete in a problematic way, and by changing the name we admit that we were always really trying to use TI for counting uniformly, and zoneinfo for civilly desirable things like telling people when to open and close their shops. After the change I propose, yes, there would be systems still producing TI and calling it UTC, but that's just a name for one international standard vs. another. It would not be the first time a name is misapplied due to a change in cognition, and the underlying operational system would be more rigorously correct. Speaking of the wheel of karma, by the way, I suspect I understand why it was not until the 33rd CGSIC meeting in 1999-03 that Dr. Klepczynski suggested abandoning leap seconds: http://ad.usno.navy.mil/wds/history/markowitz.html -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Fri Mar 28 12:04:49 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 16:04:49 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 08:19:05 MST." <20080328151905.GA25223@ucolick.org> Message-ID: <5764.1206720289@critter.freebsd.dk> In message <20080328151905.GA25223 at ucolick.org>, Steve Allen writes: >On Fri 2008-03-28T11:42:25 +0000, Poul-Henning Kamp hath writ: >> Simply not true. A good place to start is the FreeBSD ports-tree >> which contains about 18000 piece of open source software. > >Is there a detailed inventory of how many of those break in 2038? That's an interesting question. Today, on a 32bit system, they invariably all do, but running on a 64 bit system, surprising many seems to work correctly. >And how many break as binaries vs. how many would work if recompiled? Well, al 32bit binaries break (by definition), but I'm not sure binary distribution of programs is much of a concern in this respect. For the average software package, there is still a good 10 releases before 2038. >If the ITU-R cannot find a unilateral stance then it may be time to >start thinking compromise. I don't think it is as much about compromise as capitulation to reality: Even if we decided to fix time_t's little red wagon for good, and got the economic resources to do so, we would be very hard pressed to find the competent man-power to carry it out reliably. And compared to humanitys other pending issues, it would be very hard to justify the priority for this task. >Is getting the leaps out of the system's time_t worth the other hassle? If you compare with the other crap we put up with from computers, and the sheer mindbogglingness of the workarounds people put up with, I am sure that the disappearance of leap seconds would not even register on the publics radar. My personal preference, would be that we create a new definition of time representation for computers, preferably in a binary format so the math gets faster and less buggy. Ufortunately, a 64bit arithmetic type is not enough to give us both range and resolution. Some have proposed a dual-modus format, technically a "one-bit exponent floating point" format, that trades resolution for range with a mode-bit: Calendar: 55i.8f + '0' (1.1 bilion years, 5ms resolution) Time: 33i.30f + '1' (272 years, approx 1ns resolution) But I would advocate against that on both efficiency and error detection reasons. Another option is to have two different types: calendar_t 54i.10f (570My / 1ms) utc_t 34i.30f (544y / 1ns) Provided the bad effects of mixing them are bad enough, that can work. My personal preference would be to bite the bullet and live with the 128bit memory hit: utc_t 64i.64f (big enough, small enough) Provided we get 10 years notice of leapseconds, that timescale can contain leap seconds. If we don't get at least 10 years notice, it should not suffer from them. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Mar 28 12:12:46 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 16:12:46 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 08:33:41 MST." <20080328153341.GA25300@ucolick.org> Message-ID: <5819.1206720766@critter.freebsd.dk> In message <20080328153341.GA25300 at ucolick.org>, Steve Allen writes: >On Fri 2008-03-28T15:28:53 +0000, Tony Finch hath writ: >> The POSIX standard guarantees that what Warner wrote is correct. > >The POSIX standard is in denial about leap seconds with respect to >UTC. I don't know about international standards, but in people I'm >sure that's not a good sign, and I try to avoid such. I have long maintained that POSIX was one of the biggest and most costly mistakes in international standards. All the trouble with POSIX can be traced back to the fact that it standardized backwards instead of forwards, or in other words: a "rubberstamp standard" instead of a "roadmap standard". But just like leapseconds, POSIX is a mistake that is with us here today, and we will have to resolve the inconsistencies somehow. But our problems with POSIX may pale soon, when the politically ram-rodded, 7000 pages long OOXML standard for "office and business documents gets ratified by ISO as a "rubberstamp" standard. As far as I know that standard gets none of leap years, timezones much less leap seconds right. Behold the power of computers in the hand of the unwashed masses. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sla at ucolick.org Fri Mar 28 13:08:48 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 10:08:48 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <5764.1206720289@critter.freebsd.dk> References: <20080328151905.GA25223@ucolick.org> <5764.1206720289@critter.freebsd.dk> Message-ID: <20080328170848.GA25646@ucolick.org> On Fri 2008-03-28T16:04:49 +0000, Poul-Henning Kamp hath writ: > My personal preference would be to bite the bullet and live with > the 128bit memory hit: > > utc_t 64i.64f (big enough, small enough) Whereas I am not against the notion of such, I find that nomenclature to be problematic, for UTC did not exist prior to 1960. We must not forget the examples of Sweden http://en.wikipedia.org/wiki/February_30 and that, contrary to what everyone thought at the time, Julius was assasinated on March 14, not 15 http://en.wikipedia.org/wiki/Roman_calendar#Converting_pre-Julian_dates It is never possible to get people to fix their notion of what time they thought it was. Any epoch-based proleptic time scale using uniform counting is a conventional artifice which is unlikely to correspond to any other retrospective scheme in current use or any scheme which was contemporary at the given epoch. Even if it is a broadly published international standard, nothing constrains posterity from misusing the definition, or even changing its notion of the meaning of a time scale and creating more such examples. It seems unlikely to me that any organization has the standing to assert an unambiguous time scale that is both operational and comprehensive across history. If anyone gets close, I am sure that there are obsessive/compulsive programmers who will write conversion libraries in all the currently popular computer languages, and I am also sure that those libraries will be ignored by a lot of systems which do not care to be comprehensive. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From cowan at ccil.org Fri Mar 28 13:17:15 2008 From: cowan at ccil.org (John Cowan) Date: Fri, 28 Mar 2008 13:17:15 -0400 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328153341.GA25300@ucolick.org> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <47ECEC0D.6030405@cox.net> <20080328153341.GA25300@ucolick.org> Message-ID: <20080328171714.GJ30818@mercury.ccil.org> Steve Allen scripsit: > The POSIX standard is in denial about leap seconds with respect to > UTC. I don't know about international standards, but in people I'm > sure that's not a good sign, and I try to avoid such. Not exactly. What it denies is that there is necessarily 1s between values of time_t that differ by 1. Sometimes there is 2s. -- "Well, I'm back." --Sam John Cowan From phk at phk.freebsd.dk Fri Mar 28 13:33:13 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 17:33:13 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 10:08:48 MST." <20080328170848.GA25646@ucolick.org> Message-ID: <6120.1206725593@critter.freebsd.dk> In message <20080328170848.GA25646 at ucolick.org>, Steve Allen writes: >On Fri 2008-03-28T16:04:49 +0000, Poul-Henning Kamp hath writ: >> My personal preference would be to bite the bullet and live with >> the 128bit memory hit: >> >> utc_t 64i.64f (big enough, small enough) > >Whereas I am not against the notion of such, I find that nomenclature >to be problematic, for UTC did not exist prior to 1960. Agreed, but at least that is only a matter of educating historians and not politicians and pedestrians. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From greg.hennessy at cox.net Fri Mar 28 14:37:18 2008 From: greg.hennessy at cox.net (Greg Hennessy) Date: Fri, 28 Mar 2008 14:37:18 -0400 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <47ECEC0D.6030405@cox.net> Message-ID: <20080328183718.GA19897@cox.net> > > > although naive math is, well, naive, more code exists that assumes, > > > for example, that midnight it time_t % 86400 == 0 than you want to > > > believe. Changing this is really bad karma. > > > > The current situation is that code like your example does not accurately > > reflect reality. > > The POSIX standard guarantees that what Warner wrote is correct. I'm not arguing if Warner is correct or not if he claims that POSIX claims that time_t % 86400 == 0 means midnight. I'm also not arguing that he is correct that lots of code assumes this. My claim is that if POSIX defines time_t % 86400 == 0 as being midnight than POSIX doesn't reflect reality, since people think "midnight" as being UTC rather than POSIX. POSIX may define 2+2=5, but if it did it wouldn't be correct. From phk at phk.freebsd.dk Fri Mar 28 14:44:32 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 18:44:32 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 14:37:18 -0400." <20080328183718.GA19897@cox.net> Message-ID: <6362.1206729872@critter.freebsd.dk> In message <20080328183718.GA19897 at cox.net>, Greg Hennessy writes: >My claim is that if POSIX defines time_t % 86400 == 0 as being >midnight than POSIX doesn't reflect reality, [...] Well, POSIX clearly doesn't match the scientific definition of UTC, but as which of the two is more "real" is mostly a matter of philosophy I think. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From cowan at ccil.org Fri Mar 28 15:15:47 2008 From: cowan at ccil.org (John Cowan) Date: Fri, 28 Mar 2008 15:15:47 -0400 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328183718.GA19897@cox.net> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <47ECEC0D.6030405@cox.net> <20080328183718.GA19897@cox.net> Message-ID: <20080328191547.GM30818@mercury.ccil.org> Greg Hennessy scripsit: > My claim is that if POSIX defines time_t % 86400 == 0 as being > midnight than POSIX doesn't reflect reality, since people think > "midnight" as being UTC rather than POSIX. When it's midnight UTC, a properly time-aware Posix system *will* report that time_t % 86400 == 0. That's about as congruent to reality is any system can get. Unfortunately, it reports the same thing at 23:59:60 UTC on days when such a second exists. -- A rose by any other name John Cowan may smell as sweet, http://www.ccil.org/~cowan but if you called it an onion cowan at ccil.org you'd get cooks very confused. --RMS From imp at bsdimp.com Fri Mar 28 15:40:20 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri, 28 Mar 2008 13:40:20 -0600 (MDT) Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <6362.1206729872@critter.freebsd.dk> References: <20080328183718.GA19897@cox.net> <6362.1206729872@critter.freebsd.dk> Message-ID: <20080328.134020.-1350499494.imp@bsdimp.com> In message: <6362.1206729872 at critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20080328183718.GA19897 at cox.net>, Greg Hennessy writes: : : >My claim is that if POSIX defines time_t % 86400 == 0 as being : >midnight than POSIX doesn't reflect reality, [...] : : Well, POSIX clearly doesn't match the scientific definition of : UTC, but as which of the two is more "real" is mostly a matter of : philosophy I think. Well, time_t is UTC, which two unfortunate problems. The first one is that it does pander to folks who think that the start of the UTC day is a time_t % 86400 == 0. The second isn't so odd for this crowd, where the notion of a variable radix notation is accepted without question: time_t is a variable radix that assigns the same value to the leap second as it does to the first second in the day. This ambiguity means that naive math works. It also means that if you have a table of leap seconds, you can compute the number of 'pps pulses' between to events, unless one of those events happens right at the leap second. The down side also is that it isn't possible to construct a time_t that will print: 2006-12-31 23:59:60 when handed to the other time functions. In fact, the other time functions are defined such that one cannot get the above even if one were to fill out the struct tm correctly because the standard mandates normalization of the struct tm before it prints things (so one can trivially add 100s to the current just by doing foo.tm_sec += 100. I'm not sure that the collapsing of the first second of the next day and the leap second, when they happen, is really any weirder than having a counter that sometimes counts to 60, but usually resets to 00 after 59. Either the special case is that sometimes we count one more, or the special case is that we use the same label to describe two different seconds. Either way, it is a pita for the software developer... Warner From phk at phk.freebsd.dk Fri Mar 28 15:45:38 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 19:45:38 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 13:40:20 CST." <20080328.134020.-1350499494.imp@bsdimp.com> Message-ID: <6619.1206733538@critter.freebsd.dk> In message <20080328.134020.-1350499494.imp at bsdimp.com>, "M. Warner Losh" write s: >Either way, it is a pita for the software developer... ... but of course, only if they happen to have heard about it being their responsibility. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From greg.hennessy at cox.net Fri Mar 28 16:13:01 2008 From: greg.hennessy at cox.net (Greg Hennessy) Date: Fri, 28 Mar 2008 16:13:01 -0400 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328.134020.-1350499494.imp@bsdimp.com> References: <20080328183718.GA19897@cox.net> <6362.1206729872@critter.freebsd.dk> <20080328.134020.-1350499494.imp@bsdimp.com> Message-ID: <20080328201301.GA20923@cox.net> > Well, time_t is UTC, which two unfortunate problems. Is it? I always thought it was a count of the number of seconds since the start of the unix epoch, not counting leap seconds. There having been 24 (I think) leap seconds since 1970, the unix epoch, if POSIX is UTC, then it can't be true that time_d % 86400 == 0 is midnight. I've always considered time_t to be POSIX time, not UTC. From phk at phk.freebsd.dk Fri Mar 28 16:23:54 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 20:23:54 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 16:13:01 -0400." <20080328201301.GA20923@cox.net> Message-ID: <6779.1206735834@critter.freebsd.dk> In message <20080328201301.GA20923 at cox.net>, Greg Hennessy writes: >> Well, time_t is UTC, which two unfortunate problems. > >Is it? I always thought it was a count of the number of seconds since >the start of the unix epoch, not counting leap seconds. ] Coordinated Universal Time (UTC) includes leap seconds. However, ] in POSIX time (seconds since the Epoch), leap seconds are ignored ] (not applied) to provide an easy and compatible method of computing ] time differences. Broken-down POSIX time is therefore not necessarily ] UTC, despite its appearance. More at A.4.14 in: http://www.opengroup.org/onlinepubs/009695399/xrat/xbd_chap04.html -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From sla at ucolick.org Fri Mar 28 16:38:45 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 13:38:45 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328201301.GA20923@cox.net> References: <20080328183718.GA19897@cox.net> <6362.1206729872@critter.freebsd.dk> <20080328.134020.-1350499494.imp@bsdimp.com> <20080328201301.GA20923@cox.net> Message-ID: <20080328203845.GA26462@ucolick.org> On Fri 2008-03-28T16:13:01 -0400, Greg Hennessy hath writ: > Is it? I always thought it was a count of the number of seconds since > the start of the unix epoch, not counting leap seconds. > > There having been 24 (I think) leap seconds since 1970, the unix > epoch, if POSIX is UTC, then it can't be true that time_d % 86400 == 0 > is midnight. > > I've always considered time_t to be POSIX time, not UTC. POSIX time_t counts mean solar seconds. Admittedly, that's not what the spec says, but that's what it does. And that's what it has to do if it expects the time_t to stay in phase with the calendar. This is sortof like the time scale implicit in LORAN-C. The LORAN-C networks have Times of Coincidence (TOCs) when an entire chain is in phase, and those TOCs happen at intervals based on the number of seconds elapsed since the TAI epoch, 1958-01-01. Except... Until 1972 the LORAN networks broadcast according to the time scale which was approximating UT2 and which became called UTC, and after 1972 their time scale has tracked TAI. So if you ask what time it is according to LORAN-C you get a value 10 s different than TAI, because the length of the LORAN-C second changed after it missed 10 TAI seconds. And the inception of cesium at the LORAN-C transmitters matches rather well with 1966 (the date at which the BIH last adjusted the length of the UTC second) and also right around the time that the CCIR working parties started seriously discussing leap seconds. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From imp at bsdimp.com Fri Mar 28 16:22:22 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Fri, 28 Mar 2008 14:22:22 -0600 (MDT) Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328201301.GA20923@cox.net> References: <6362.1206729872@critter.freebsd.dk> <20080328.134020.-1350499494.imp@bsdimp.com> <20080328201301.GA20923@cox.net> Message-ID: <20080328.142222.232929390.imp@bsdimp.com> In message: <20080328201301.GA20923 at cox.net> Greg Hennessy writes: : > Well, time_t is UTC, which two unfortunate problems. : : Is it? I always thought it was a count of the number of seconds since : the start of the unix epoch, not counting leap seconds. : : There having been 24 (I think) leap seconds since 1970, the unix : epoch, if POSIX is UTC, then it can't be true that time_d % 86400 == 0 : is midnight. Why not? You didn't read the rest of my post. It would be true only if time_t were a uniform radix notation (which is a fancy way of saying it mapped all seconds 1-1 and onto the number). It doesn't. It maps some seconds onto the same value, keeping the above property. How is that any different than the ITU defining UTC to generally behave as time has behaved for centuries, except that leap seconds have a new notation (the :60 stuff)? They essentially changed the definition of a broken down time from the centuries old uniform radix to one with a non-uniform radix. Time_t can be viewed in a similar manner. If you insist that time_t be monotonic and a 1-1 onto mapping, then you are correct. However, it is neither of those things... Again, it is a pain no matter what you do with leap seconds. Warner From seaman at noao.edu Fri Mar 28 18:14:29 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:14:29 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328.142222.232929390.imp@bsdimp.com> References: <6362.1206729872@critter.freebsd.dk> <20080328.134020.-1350499494.imp@bsdimp.com> <20080328201301.GA20923@cox.net> <20080328.142222.232929390.imp@bsdimp.com> Message-ID: <4F42C0ED-28FA-45BB-90E4-7E0452F6CC88@noao.edu> Working backwards through the messages. On Mar 28, 2008, at 1:22 PM, M. Warner Losh wrote: > How is that any different than the ITU defining UTC to generally > behave as time has behaved for centuries, except that leap seconds > have a new notation (the :60 stuff)? ITU didn't create UTC since they didn't exist at the time. Grep for messages from Mark Calabretta as to why UTC isn't multi-valued. Rob Seaman NOAO From seaman at noao.edu Fri Mar 28 18:18:16 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:18:16 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <6362.1206729872@critter.freebsd.dk> References: <6362.1206729872@critter.freebsd.dk> Message-ID: <8A9228BB-3F45-4644-87A6-E379BF875409@noao.edu> On Mar 28, 2008, at 11:44 AM, Poul-Henning Kamp wrote: > Well, POSIX clearly doesn't match the scientific definition of > UTC, but as which of the two is more "real" is mostly a matter of > philosophy I think. Both are human constructs. It is mean solar time that is real, that is, the sidereal day augmented by 3m56s to account for annually lapping the sun. Rob Seaman NOAO From seaman at noao.edu Fri Mar 28 18:22:01 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:22:01 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328170848.GA25646@ucolick.org> References: <20080328151905.GA25223@ucolick.org> <5764.1206720289@critter.freebsd.dk> <20080328170848.GA25646@ucolick.org> Message-ID: <9C2E08C7-F8D8-4B07-98F7-B3251CC4A34A@noao.edu> On Mar 28, 2008, at 10:08 AM, Steve Allen wrote: > It seems unlikely to me that any organization has the standing to > assert an unambiguous time scale that is both operational and > comprehensive across history. Indeed. This is a function of Mother Earth. Smash a clock offering a representation of mean solar time. The repaired clock could be reset via observation from first principles. Smash an atomic clock. Then what? Rob Seaman NOAO From seaman at noao.edu Fri Mar 28 18:23:50 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:23:50 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <5819.1206720766@critter.freebsd.dk> References: <5819.1206720766@critter.freebsd.dk> Message-ID: <66AC0D95-1918-4A4F-906D-2A4F23F394C9@noao.edu> On Mar 28, 2008, at 9:12 AM, Poul-Henning Kamp wrote: > But our problems with POSIX may pale soon, when the politically > ram-rodded, 7000 pages long OOXML standard for "office and business > documents gets ratified by ISO as a "rubberstamp" standard. > > As far as I know that standard gets none of leap years, timezones > much less leap seconds right. And we're to trust the international standards process to define the fundamental architecture of timekeeping? From seaman at noao.edu Fri Mar 28 18:36:03 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:36:03 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <5764.1206720289@critter.freebsd.dk> References: <5764.1206720289@critter.freebsd.dk> Message-ID: <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> On Mar 28, 2008, at 9:04 AM, Poul-Henning Kamp wrote: > Even if we decided to fix time_t's little red wagon for > good, and got the economic resources to do so, we would be very > hard pressed to find the competent man-power to carry it out reliably. I'm fascinated by your choice of this line of argument. People are incompetent - let's give up. Why then should we care about any of the trappings of modern civilization? However complex the current worldwide system of systems comprising our civilization, it will only get more complex. Whenever we choose to address some technological issue, it will be better to use system engineering best practices to attempt to constrain that complexity. > If you compare with the other crap we put up with from computers, > and the sheer mindbogglingness of the workarounds people put up > with, I am sure that the disappearance of leap seconds would not > even register on the publics radar. System engineering is as much or more about characterizing the problem as about offering a solution. Your personal surety is of little benefit to this process. Risks that aren't characterized in advance are likely to register on the public radar (perhaps literally) in retrospect. > My personal preference, would be that we create a new definition > of time representation for computers, preferably in a binary format > so the math gets faster and less buggy. This is a nice discussion of options (absolutely no irony here). My central point all these long years is that we have yet to even scratch the surface of capturing coherent requirements for civil timekeeping in the modern world. Before we design a solution (or scrap the interim solution that we already have), wouldn't it make sense to figure out the full nature of the problem it is meant to solve? > Provided we get 10 years notice of leapseconds, that timescale > can contain leap seconds. If we don't get at least 10 years notice, > it should not suffer from them. We would all be happy with all the notice we could get. This is an orthogonal concept to the best scheduling cadence for clock updates of whatever sort. It doesn't take much insight into human nature to think that a monthly cadence will get more productive attention than a decadal or millennial cadence. Rob Seaman NOAO From seaman at noao.edu Fri Mar 28 18:45:56 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:45:56 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328160409.GA25374@ucolick.org> References: <20080328041505.GA20152@ucolick.org> <4353.1206704545@critter.freebsd.dk> <20080328.062827.-957833510.imp@bsdimp.com> <20080328160409.GA25374@ucolick.org> Message-ID: <14609592-6A2D-4089-BAB8-D4F4FC1068FA@noao.edu> On Mar 28, 2008, at 9:04 AM, Steve Allen wrote: > But if we call POSIX time_t by a new name (say TI) which has > international status and properties which match the specified > characteristics of time_t then what we have is enlightenment. How about calling it GPS? The assertion is that TAI itself is unacceptable as a practical time scale. The notion is that we'll turn UTC into that time scale. However, by doing so, UTC will no longer be a flavor of Universal Time. The largely unstated assumption is that folks needing actual Universal Time will use UT1 instead. Note, however, that UT1 is unacceptable as a practical time scale since like TAI it is retroactively computed. Rather, how about implementing Steve's scheme, but using GPS and UTC? Both would remain practical and transportable time scales. Both are known to the public already. GPS is clearly the most flagrantly successful timekeeping standard by any marketing standpoint. And after all, this is really just the "moveable timezone" notion of civil timekeeping, but turned into a functional system concept for evaluation purposes. Simply saying "we'll make up the difference by smooshing the timezones around as needed" is not equivalent to a coherent plan. That said, any such system needs to pass through a system engineering planning process before it can be deemed to be a solution to any problem. (Because otherwise there will be no clearly described problem to be solved.) Rob Seaman NOAO From sla at ucolick.org Fri Mar 28 18:55:36 2008 From: sla at ucolick.org (Steve Allen) Date: Fri, 28 Mar 2008 15:55:36 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> References: <5764.1206720289@critter.freebsd.dk> <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> Message-ID: <20080328225536.GA27068@ucolick.org> On Fri 2008-03-28T15:36:03 -0700, Rob Seaman hath writ: > >Provided we get 10 years notice of leapseconds, that timescale > >can contain leap seconds. If we don't get at least 10 years notice, > >it should not suffer from them. > > We would all be happy with all the notice we could get. > > This is an orthogonal concept to the best scheduling cadence for clock > updates of whatever sort. It doesn't take much insight into human > nature to think that a monthly cadence will get more productive > attention than a decadal or millennial cadence. The "question" that the ITU-R has posed for itself to answer since this process began is really more than one question. 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. The questions of how much notice is needed for a leap second, and how close UTC has to stay to UT1 (or, given that UT1 isn't really mean solar time anymore, whatever may be deemed better than UT1 for that purpose) can then be answered separately, and more leisurely. The answers can even be changed without seriously affecting the uniformly incrementing operational systems using the broadcast time scale. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From seaman at noao.edu Fri Mar 28 18:55:26 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 15:55:26 -0700 Subject: [LEAPSECS] a modest proposal In-Reply-To: <20080328.062254.-432840016.imp@bsdimp.com> References: <20080211184032.GA21325@ucolick.org> <20080328041249.GA20110@ucolick.org> <20080328.062254.-432840016.imp@bsdimp.com> Message-ID: <94EA5BE2-082D-455A-922E-C65FF341BDD6@noao.edu> On Mar 28, 2008, at 5:22 AM, M. Warner Losh wrote: > As someone who has been ill-treated by > leapseconds, I fail to see why they are necessary in a society that > accepts > 1hr deviation from solar mean time... 1) Again, this is confusing apparent solar time with mean solar time, periodic effects with secular effects. Surely we would all choose to solve some other less political technical issue by first correctly modeling the physical behavior. 2) Have you been ill-treated by leapseconds or by badly designed and implemented systems? 3) System engineering best practices exist precisely to make issues evident to all stakeholders who may indeed fail to see the nature of those issues at the beginning of the project. We have yet to even begin a coherent process of characterizing what the project "Civil Timekeeping v2.0" would consist of. Since the current interim solution is viable for several centuries yet, what is our hurry? Rob Seaman NOAO From phk at phk.freebsd.dk Fri Mar 28 19:06:51 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 23:06:51 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 15:23:50 MST." <66AC0D95-1918-4A4F-906D-2A4F23F394C9@noao.edu> Message-ID: <1041.1206745611@critter.freebsd.dk> In message <66AC0D95-1918-4A4F-906D-2A4F23F394C9 at noao.edu>, Rob Seaman writes: >On Mar 28, 2008, at 9:12 AM, Poul-Henning Kamp wrote: > >> But our problems with POSIX may pale soon, when the politically >> ram-rodded, 7000 pages long OOXML standard for "office and business >> documents gets ratified by ISO as a "rubberstamp" standard. >> >> As far as I know that standard gets none of leap years, timezones >> much less leap seconds right. > >And we're to trust the international standards process to define the >fundamental architecture of timekeeping? I don't know about "trust", but "live with" ? Yes, unfortunately. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Fri Mar 28 19:07:50 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 16:07:50 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <4353.1206704545@critter.freebsd.dk> References: <4353.1206704545@critter.freebsd.dk> Message-ID: <38CEB26C-C998-4933-9BF7-272201BA7B34@noao.edu> On Mar 28, 2008, at 4:42 AM, Poul-Henning Kamp wrote: > This is exactly the flagday that will make the upgrades to a few > hundered telescopes look like peanuts. In grad school one of my housemates was a Swedish postdoc with an inordinate fondness for Jack Lord and Hawaii Five-O (http://www.youtube.com/watch?v=rNk_wlqFG5o ) Per had an entertaining description of the flagday when Sweden switched to right-side driving in 1967. Don't sell the entertainment value short as a way to bring timekeeping to the attention of a vast new public. If it's peanuts to you, perhaps you'll help with our funding for this "upgrade"? What new features should we expect in this release? :-) From phk at phk.freebsd.dk Fri Mar 28 19:12:57 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 23:12:57 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 15:36:03 MST." <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> Message-ID: <1074.1206745977@critter.freebsd.dk> In message <3750F624-75C3-49A7-92A1-A2DE54AC40DA at noao.edu>, Rob Seaman writes: >However complex the current worldwide system of systems comprising our >civilization, it will only get more complex. There are actually a significant undercurrent that indicates that this will not be the case. Most recent technology, while rich in features, gets used to nowhere near it's technological potential, because people simply cannot figure it all out. The thing that seems to be widely overlooked by technologists, possibly by the high-IQ crowd in general, is that Moores law does not apply to wetware, and consequently, there very much is a fixed upper limit for how much technology you can push on the general population. We can do the stiff upper-lip and thumb our noses at this well documented phenomena, or we can accept it and realize that successful technology in the future is that which makes things simpler instead of more complex for people. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Mar 28 19:14:35 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 23:14:35 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 15:45:56 MST." <14609592-6A2D-4089-BAB8-D4F4FC1068FA@noao.edu> Message-ID: <1083.1206746075@critter.freebsd.dk> In message <14609592-6A2D-4089-BAB8-D4F4FC1068FA at noao.edu>, Rob Seaman writes: >On Mar 28, 2008, at 9:04 AM, Steve Allen wrote: > >> But if we call POSIX time_t by a new name (say TI) which has >> international status and properties which match the specified >> characteristics of time_t then what we have is enlightenment. > >How about calling it GPS? Only if you can convince ISO9000 consultants that there is a traceability from this timescale (as distributed by NTP ?) to UTC which forms the basis of legal timekeeping. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at phk.freebsd.dk Fri Mar 28 19:22:35 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Fri, 28 Mar 2008 23:22:35 +0000 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: Your message of "Fri, 28 Mar 2008 16:07:50 MST." <38CEB26C-C998-4933-9BF7-272201BA7B34@noao.edu> Message-ID: <1190.1206746555@critter.freebsd.dk> In message <38CEB26C-C998-4933-9BF7-272201BA7B34 at noao.edu>, Rob Seaman writes: >Per had an entertaining description of the flagday when Sweden >switched to right-side driving in 1967. You know the danish version of that story ? They were afraid that it would be total mayhem to do it in one go, so the phased it in: First the lorrys and trucks, then some days later the smaller cars :-) Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From seaman at noao.edu Fri Mar 28 19:30:05 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 16:30:05 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <1074.1206745977@critter.freebsd.dk> References: <1074.1206745977@critter.freebsd.dk> Message-ID: <0461273A-EA2F-4E16-B2AA-A82EFCD24D79@noao.edu> On Mar 28, 2008, at 4:12 PM, Poul-Henning Kamp wrote: > The thing that seems to be widely overlooked by technologists, > possibly by the high-IQ crowd in general, is that Moores law does > not apply to wetware, and consequently, there very much is a fixed > upper limit for how much technology you can push on the general > population. Excellent points - I'll buy the first round if we're ever at the same conference. Most Mac users would take credit for saying it first :-) "High-IQ" is an adjective devoid of semantic content, however. See SJ Gould's "Mismeasure of Man" or Gardner's Multiple Intelligences. Binet invented IQ to discover the underperforming tail of the curve, not "smart people". > We can do the stiff upper-lip and thumb our noses at this well > documented phenomena, or we can accept it and realize that successful > technology in the future is that which makes things simpler instead > of more complex for people. 100% agree, but the definition of "simpler" is "maps elegantly onto the real world". The Earth does rotate, the Moon does steal its angular momentum, the Sun does illuminate our lives. From seaman at noao.edu Fri Mar 28 19:32:11 2008 From: seaman at noao.edu (Rob Seaman) Date: Fri, 28 Mar 2008 16:32:11 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <1083.1206746075@critter.freebsd.dk> References: <1083.1206746075@critter.freebsd.dk> Message-ID: <4BD9E0DF-ADE3-449F-AEEC-1C9C220F2819@noao.edu> On Mar 28, 2008, at 4:14 PM, Poul-Henning Kamp wrote: > Only if you can convince ISO9000 consultants that there is a > traceability > from this timescale (as distributed by NTP ?) to UTC which forms the > basis of legal timekeeping. Ahoy! A requirement has been discovered! From sla at ucolick.org Sat Mar 29 14:07:59 2008 From: sla at ucolick.org (Steve Allen) Date: Sat, 29 Mar 2008 11:07:59 -0700 Subject: [LEAPSECS] proliferation Message-ID: <20080329180759.GB3992@ucolick.org> Picking up a note from the IETF NTP Working group https://lists.ntp.org/pipermail/ntpwg/2008-March/001159.html We see that Microsoft's NTP implementation does not play well with the NTP being run by national standards labs, and David Mills suggests something a lot like proliferation of time scales: > This is quickly becoming a failed mission. If Microsoft insists > on propagating MS-SNTP, they should provide their own > infrastructure independent of the existing NTP infrastructure. I recall Rodney King during the 1992 LA Riots: People, I just want to say, you know, can we all get along? Can we get along? Proliferation is a natural aspect of human existence. Is there any way to inhibit it other than to provide a solution so well documented that everyone finds out about it in grammar school and so compellingly comprehensively correct that nobody considers making something different? By its charter the ITU-R can't do the "well documented" part, and by its structure and history it hasn't done the "comprehensively correct" part. The BIPM and IERS can. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From mcalabre at atnf.CSIRO.AU Mon Mar 31 00:05:48 2008 From: mcalabre at atnf.CSIRO.AU (Mark Calabretta) Date: Mon, 31 Mar 2008 15:05:48 +1100 Subject: [LEAPSECS] Seems relevant somehow Message-ID: ------- Forwarded Message Date: Mon 2008/03/31 14:28:15 +1100 From: ser911 at csiro.au To: Subject: Client Notification: Daylight Savings Issues Client Notification: Daylight Savings Issues IM&T wish to advise that a number of Daylight Savings issues are currently being experienced throughout CSIRO, similar to those being felt throughout many government agencies and organisations around Australia. Last night, Western Australia returned to standard time however NSW, the ACT, Victoria and South Australia recently decided to align with Tasmania and remain on summer time until April 6. As a result, a large number of electronic devices have automatically adjusted their time back one hour. Specific issues identified within CSIRO at this time include: * Blackberry handsets - handsets have reverted back one hour resulting in the displayed time and some appointments being displayed incorrectly. * Outlook calendars - recurring meetings may be one hour out for the week ending Friday 4th April. If unsure, please confirm times with meeting organisers. * CISCO IP Phones - some IP phones displays will also be one hour out. A patch is being applied to correct this and all phones will be corrected prior to start of business tomorrow, Tuesday 1st April. If you require that this update is applied prior to this time, please contact the Enterprise Service Desk. IM&T are working with vendors in an effort to correct these issues. Further information will be provided through IM&T's Incident Information page (http://intranet.csiro.au/alerts). Contact: If you have any questions please call the CSIRO Service Desk on 02 6276 6666 or 96 6666. CSIRO Service Desk CSIRO Information Management & Technology (IM&T) 2 Wilf Crane Crescent, Yarralumla ACT 2600 Ph 61 2 6276 6666 * Fax 61 2 6276 6500 Email: servicedesk at csiro.au Web: http://www.csiro.au/intranet/computing/index.htm From sla at ucolick.org Mon Mar 31 01:27:36 2008 From: sla at ucolick.org (Steve Allen) Date: Sun, 30 Mar 2008 22:27:36 -0700 Subject: [LEAPSECS] Seems relevant somehow In-Reply-To: References: Message-ID: <20080331052736.GA1469@ucolick.org> On Mon 2008-03-31T15:05:48 +1100, Mark Calabretta hath writ: > Last night, Western Australia returned to standard time however NSW, the > ACT, Victoria and South Australia recently decided to align with > Tasmania and remain on summer time until April 6. I would love to know the meaning of "recently". Was it 6 months of notice, or less than Daniel Gambis gives? -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From sla at ucolick.org Mon Mar 31 01:35:41 2008 From: sla at ucolick.org (Steve Allen) Date: Sun, 30 Mar 2008 22:35:41 -0700 Subject: [LEAPSECS] Seems relevant somehow In-Reply-To: <20080331052736.GA1469@ucolick.org> References: <20080331052736.GA1469@ucolick.org> Message-ID: <20080331053541.GA1522@ucolick.org> On Sun 2008-03-30T22:27:36 -0700, Steve Allen hath writ: > I would love to know the meaning of "recently". > > Was it 6 months of notice, or less than Daniel Gambis gives? Hmmm, at least for NSW it was less than 6 months. Legislation passed 2007-10-23 http://www.lawlink.nsw.gov.au/lawlink/cru/ll_cru.nsf/pages/cru_daylightsaving 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. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From phk at phk.freebsd.dk Mon Mar 31 01:46:38 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Mon, 31 Mar 2008 05:46:38 +0000 Subject: [LEAPSECS] Seems relevant somehow In-Reply-To: Your message of "Sun, 30 Mar 2008 22:35:41 MST." <20080331053541.GA1522@ucolick.org> Message-ID: <15249.1206942398@critter.freebsd.dk> In message <20080331053541.GA1522 at ucolick.org>, Steve Allen writes: >On Sun 2008-03-30T22:27:36 -0700, Steve Allen hath writ: >> I would love to know the meaning of "recently". >> >> Was it 6 months of notice, or less than Daniel Gambis gives? > >Hmmm, at least for NSW it was less than 6 months. >Legislation passed 2007-10-23 > >http://www.lawlink.nsw.gov.au/lawlink/cru/ll_cru.nsf/pages/cru_daylightsaving > >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. 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. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From jhein at timing.com Mon Mar 31 02:54:57 2008 From: jhein at timing.com (John Hein) Date: Mon, 31 Mar 2008 00:54:57 -0600 Subject: [LEAPSECS] Seems relevant somehow In-Reply-To: <20080331053541.GA1522@ucolick.org> References: <20080331052736.GA1469@ucolick.org> <20080331053541.GA1522@ucolick.org> Message-ID: <18416.35521.590622.470702@gromit.timing.com> 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. From seaman at noao.edu Mon Mar 31 03:55:55 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 31 Mar 2008 00:55:55 -0700 Subject: [LEAPSECS] the inescapability of feedback In-Reply-To: <20080331053541.GA1522@ucolick.org> References: <20080331052736.GA1469@ucolick.org> <20080331053541.GA1522@ucolick.org> Message-ID: 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 From dot at dotat.at Mon Mar 31 07:20:06 2008 From: dot at dotat.at (Tony Finch) Date: Mon, 31 Mar 2008 12:20:06 +0100 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080328225536.GA27068@ucolick.org> References: <5764.1206720289@critter.freebsd.dk> <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> <20080328225536.GA27068@ucolick.org> Message-ID: 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 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. From clive at demon.net Mon Mar 31 07:25:33 2008 From: clive at demon.net (Clive D.W. Feather) Date: Mon, 31 Mar 2008 12:25:33 +0100 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: References: <5764.1206720289@critter.freebsd.dk> <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> <20080328225536.GA27068@ucolick.org> Message-ID: <20080331112533.GR82714@finch-staff-1.thus.net> 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: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From sla at ucolick.org Mon Mar 31 10:01:41 2008 From: sla at ucolick.org (Steve Allen) Date: Mon, 31 Mar 2008 07:01:41 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: References: <5764.1206720289@critter.freebsd.dk> <3750F624-75C3-49A7-92A1-A2DE54AC40DA@noao.edu> <20080328225536.GA27068@ucolick.org> Message-ID: <20080331140141.GA14032@ucolick.org> 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 WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From jhein at timing.com Mon Mar 31 10:06:54 2008 From: jhein at timing.com (John E Hein) Date: Mon, 31 Mar 2008 08:06:54 -0600 Subject: [LEAPSECS] the inescapability of feedback In-Reply-To: References: <20080331052736.GA1469@ucolick.org> <20080331053541.GA1522@ucolick.org> Message-ID: <18416.61438.30460.138558@gromit.timing.com> 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. From seaman at noao.edu Mon Mar 31 13:43:12 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 31 Mar 2008 10:43:12 -0700 Subject: [LEAPSECS] operational time -- What's in a name? References: <0252D543-5185-45F8-98EB-F80907B51CE3@noao.edu> Message-ID: <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> Clive D.W. Feather wrote: > Tony Finch said: >> So you think that the millions of existing radio controlled clocks >> and watches should stop showing civil time? > > They already do. Case in point: When the local Red Cross center relocated a couple of years ago, new RC "atomic" clocks appeared over each blood donor station. - With an 8 week sampling interval, I can report that for the first six months or so, the clocks were synchronized to the radio with low dispersion. - Around the six month mark (say, around the time DST changed for the first time), the dispersion kicked upward for several of the clocks but most remained synchronized. - Around the one year mark it was about half and half - that is, it looked like half the clocks were now running open loop. Presumably batteries were changed, etc. - At 1.5 years, the Red Cross introduced a new hand held data entry device for scanning bar codes from the bags, etc. This has a printer such that much less data is handwritten. The device also appears to include its own clock (perhaps synchronized across the system). The wall clocks seem to fill a purely utility purpose now. - After two years, the clocks are all off the grid with no two synchronized. Each system we design and use has unique relative and absolute timekeeping requirements. It is hard, however, to see any problem for which the current generation of consumer RC clocks is an appropriate solution. 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). Precisely by advertising such clocks as whizbang atomic clocks, the user community will relax their own vigilance (never much to begin with). Rather, a clock that claims extreme accuracy (through overtly extreme precision) must ultimately be layered on a well designed system of traceable time signals. RC time signals are meaningless (no matter the underlying timescale) if the logistical issues (as described by Steve, for instance) are ignored. Logistics keys on developing a coherent model of the system being operated. It is not enough to simply create a single perfect clock. The perfect clock demands a matching distribution protocol. The ntpwg mailing list makes interesting reading if one is tempted to believe this is a solved problem. What kind of clock does the Red Cross require? Focus on the use cases, not the technology. Rob Seaman NOAO From mgy1912 at cox.net Mon Mar 31 14:36:28 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 31 Mar 2008 11:36:28 -0700 Subject: [LEAPSECS] Seems relevant somehow References: <20080331052736.GA1469@ucolick.org><20080331053541.GA1522@ucolick.org> <18416.35521.590622.470702@gromit.timing.com> Message-ID: <003701c8935e$223533a0$9187db48@Fnord> This expresses my views about DST better than anything ever written: http://www.youtube.com/watch?v=m4AsMTYD4is ----- Original Message ----- From: "John Hein" To: "Leap Second Discussion List" Sent: Sunday, March 30, 2008 11:54 PM Subject: 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 at leapsecond.com > http://six.pairlist.net/mailman/listinfo/leapsecs > From mgy1912 at cox.net Mon Mar 31 14:45:52 2008 From: mgy1912 at cox.net (Brian Garrett) Date: Mon, 31 Mar 2008 11:45:52 -0700 Subject: [LEAPSECS] operational time -- What's in a name? References: <0252D543-5185-45F8-98EB-F80907B51CE3@noao.edu> <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> Message-ID: <003e01c8935f$722ae890$9187db48@Fnord> ----- Original Message ----- From: "Rob Seaman" To: "Leap Second Discussion List" Sent: Monday, March 31, 2008 10:43 AM Subject: Re: [LEAPSECS] operational time -- What's in a name? > Clive D.W. Feather wrote: > >> Tony Finch said: >>> So you think that the millions of existing radio controlled clocks and >>> watches should stop showing civil time? >> >> They already do. > > Case in point: When the local Red Cross center relocated a couple of > years ago, new RC "atomic" clocks appeared over each blood donor station. > [snippage] > Rather, a clock that claims extreme accuracy (through overtly extreme > precision) must ultimately be layered on a well designed system of > traceable time signals. RC time signals are meaningless (no matter the > underlying timescale) if the logistical issues (as described by Steve, > for instance) are ignored. Logistics keys on developing a coherent model > of the system being operated. > > It is not enough to simply create a single perfect clock. The perfect > clock demands a matching distribution protocol. The ntpwg mailing list > makes interesting reading if one is tempted to believe this is a solved > problem. > > What kind of clock does the Red Cross require? Focus on the use cases, > not the technology. > > Rob Seaman > NOAO > It surprises me that the Red Cross needs this kind of accuracy to begin with. The only reason a blood bank would need reasonably accurate clocks is that the units collected have to be used within 72 hours according to regulations, or so I've read. Surely at least a few minutes leeway is allowed, and NIST-traceable accuracy is overkill. (Commendable overkill, sayeth the anal-retentive geek side of me, but overkill nonetheless.) FWIW, blood banks are usually located in buildings with _lots_ of fluorescent lights. Good luck getting a radio-controlled clock to work in an environment like that. Brian Garrett From seaman at noao.edu Mon Mar 31 15:21:09 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 31 Mar 2008 12:21:09 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <003e01c8935f$722ae890$9187db48@Fnord> References: <0252D543-5185-45F8-98EB-F80907B51CE3@noao.edu> <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> <003e01c8935f$722ae890$9187db48@Fnord> Message-ID: <23BA9A7D-01F5-4946-8F39-756B13F2EAD3@noao.edu> Brian Garrett wrote: > It surprises me that the Red Cross needs this kind of accuracy to > begin with. They don't, of course. What they do have is a requirement for reasonably good relative interval timing and absolute timestamps. As with any COTS solution, the biggest problems may be with unspecified features tossed in "for free" by the vendors. > The only reason a blood bank would need reasonably accurate clocks > is that the units collected have to be used within 72 hours > according to regulations, or so I've read. 42 days currently: http://www.sciencenews.org/articles/20080322/fob1.asp They also need accurate and reasonably precise timestamps to tag their workflows, i.e., when did this event happen relative to that event for a particular center? The collection is preceded by an extensive questionnaire and health check, too. Workflow logistics is everything. The interval timing requirements are more precise. A donation must complete in a certain window of time (so many minutes) or the resulting products aren't usable. Missing the window by seconds might well cause the blood (or the donor :-) to be rejected. > Surely at least a few minutes leeway is allowed, and NIST-traceable > accuracy is overkill. Leeway might be technically acceptable, but the protocol is very specific and the logistics are not to be trifled with. Accuracy and precision are not the only issues with traceability. We shouldn't design solutions pretending that they are. > FWIW, blood banks are usually located in buildings with _lots_ of > fluorescent lights. Good luck getting a radio-controlled clock to > work in an environment like that. Like I said, the clocks remained synced through several visits suggesting that they received a signal on a regular schedule. They do turn the lights off at night, I presume. The underlying clocks are undoubtedly crap, but likely can't drift very far in a day. I do tend to donate first thing in the morning. Rob Seaman NOAO From clive at demon.net Mon Mar 31 17:36:32 2008 From: clive at demon.net (Clive D.W. Feather) Date: Mon, 31 Mar 2008 22:36:32 +0100 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> References: <0252D543-5185-45F8-98EB-F80907B51CE3@noao.edu> <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> Message-ID: <20080331213632.GB62867@finch-staff-1.thus.net> 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: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 THUS plc | | From seaman at noao.edu Mon Mar 31 19:29:07 2008 From: seaman at noao.edu (Rob Seaman) Date: Mon, 31 Mar 2008 16:29:07 -0700 Subject: [LEAPSECS] operational time -- What's in a name? In-Reply-To: <20080331213632.GB62867@finch-staff-1.thus.net> References: <0252D543-5185-45F8-98EB-F80907B51CE3@noao.edu> <874E8387-74D5-4EED-99C9-D5BB76FD2C30@noao.edu> <20080331213632.GB62867@finch-staff-1.thus.net> Message-ID: <335B129F-B3AD-43CF-97E1-CEB13B8E3759@noao.edu> Clive D.W. Feather wrote: > 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). Right. A typical such clock in the U.S. will have one set of radio buttons for Eastern/Central/Mountain/Pacific timezones and a second button labeled "DST" whose precise purpose is unclear without reading the manual. There may also be other button(s) for manual operation. I don't know what folks do in Hawaii, Alaska and other outlying timezones. At the observatory the issue we have seen is that the various conference rooms will have an array of several clocks, say Hawaii, Tucson, Washington, DC and La Serena, Chile. Originally somebody will have bought 4 spiffy "atomic" clocks without understanding that Chile is not supported. What then happens is that the clock #4 is gimmicked during northern summer (southern winter) to be Eastern Daylight Time (= Chile Standard Time, GMT-4). During the winter months (southern summer) this fails since DST in Chile is outside the range of the clocks. The model clock I'm thinking of can't have the RC manually disabled, so for half the year, the clock is either wrong or taken down from the wall or replaced with something that no longer matches the other three clocks. (I suppose someone could open it up and disable the radio.) Evidently, the requirement was never considered for a clock to be located in one place (with one radio standard), but to display time for another place. The market for a general enough clock to be portable to any timezone must be quite slim. Rob From sla at ucolick.org Mon Mar 31 21:56:14 2008 From: sla at ucolick.org (Steve Allen) Date: Mon, 31 Mar 2008 18:56:14 -0700 Subject: [LEAPSECS] the inescapability of feedback In-Reply-To: References: <20080331052736.GA1469@ucolick.org> <20080331053541.GA1522@ucolick.org> Message-ID: <20080401015614.GA12110@ucolick.org> 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 WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m From jhein at timing.com Mon Mar 31 22:13:53 2008 From: jhein at timing.com (John E Hein) Date: Mon, 31 Mar 2008 20:13:53 -0600 Subject: [LEAPSECS] the inescapability of feedback In-Reply-To: <20080401015614.GA12110@ucolick.org> References: <20080331052736.GA1469@ucolick.org> <20080331053541.GA1522@ucolick.org> <20080401015614.GA12110@ucolick.org> Message-ID: <18417.39521.328448.95045@gromit.timing.com> 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.