[LEAPSECS] USWP7A docs for 2013 September meetings
imp at bsdimp.com
Tue Aug 13 22:27:51 EDT 2013
On Aug 13, 2013, at 1:26 PM, Redman, Russell wrote:
> Very interesting.
> I note that the early draft of the "CONTRIBUTION TO THE WRC-15 AGENDA ITEM 1.14, SECTION 2/1.14/6 'METHODS TO SATISFY THE AGENDA ITEM'" includes the Chairman's Report from SG7 that includes a brief but favorable discussion of the possibility of distributing TAI alongside UTC. This is my personal favourite approach - most computer applications, including system clocks, network communications and large-scale synchronization, would benefit from the complete predictability of TAI, with applications requiring human-readable time in UTC and/or civil timescales postponed to the client code.
> The transition, of course, would be expensive. For TAI, the existing definition of time_t is already correct and system clocks running TAI will never have to deal with leap seconds. However, the libraries that implement the clock services would need to have many of their routines renamed to avoid conflicts with real UTC library codes. Network distribution software like NTP would have to be able to distinguish time servers distributing TAI from those distributing UTC, and older clients should probably not even respond to servers distibuting TAI. The UTC libraries that interpret the system clock would need to be modified to use the leap second tables, and protocols would need to be developed for the distribution of the leap second tables. All that is before we even get to the changes that client programs may or may not have to make to use the corrected service. This is, of course, precisely the point where I and many other people hesitate and wonder "Gee, do we really need
> those leap seconds???" But I think the answer is ultimately "YES" and sooner or later we will have to pay the piper.
> The rest of the documents contain the usual discussion favoring only the elimination of leap seconds, so I expect this one brief mention of an alternative will be glossed over or editted out.
> Not being an American citizen, I cannot lobby the USSG7 delegation, but those who are might take this brief opportunity to lobby for a REAL discussion of alternatives, not just a flat advocacy of one position. Although not my personal favorite approach, Steve's suggestion of adjusting for leap seconds through the timezone tables is also worth mentioning in this document as a viable alternative that can be implemented immediately.
Already has been implemented. Viable for some applications, but given the current state of the art, and a desire to not do a stat call for every single time call, longer running applications would have issues. Currently, the time functions don't state the filesystem to see if the timezone data has changed and needs to be reloaded. Even assuming computers are fast enough to not have to worry so much about this, how do these zone files get update? History has shown that people are far too slow to update, and unless everybody updates, you'll have disagreements about what time it is.
And it also doesn't fix the broken definition of time_t, nor its inability to represent actual leap seconds.
> Russell O. Redman
>> -----Original Message-----
>> From: leapsecs-bounces at leapsecond.com
>> [mailto:leapsecs-bounces at leapsecond.com] On Behalf Of Steve Allen
>> Sent: Tuesday, August 13, 2013 9:50 AM
>> To: Leap Second Discussion List
>> Subject: [LEAPSECS] USWP7A docs for 2013 September meetings
>> A preview of the documents that the USWP7A expects to contribute
>> to the ITU-R meetings next month can be seen at
>> Steve Allen <sla at ucolick.org>
>> WGS-84 (GPS)
>> UCO/Lick Observatory--ISB Natural Sciences II, Room 165
>> Lat +36.99855
>> 1156 High Street Voice: +1 831 459 3046
>> Lng -122.06015
>> Santa Cruz, CA 95064 http://www.ucolick.org/~sla/
>> Hgt +250 m
>> LEAPSECS mailing list
>> LEAPSECS at leapsecond.com
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
More information about the LEAPSECS