[LEAPSECS] final report of the UK leap seconds dialog

[Brooks Harris]

Hi Tom,

On 2015-02-05 09:18 PM, Tom Van Baak wrote:
>> Many aspects of "local time" or "civil time" are left to "common
>> practice" which is not good enough to expect uniform inter-operable
>> implementations.
> Brooks, can you give some examples?

I'm not sure what examples you mean, but perhaps comparing tz database 
and Windows registry local time entries gives an idea. Tz database is a 
tangled land of unverified jurisdictional proclamations, and Windows 
local time information comes from "on high" from Microsoft, somehow, 
somewhere. They don't match.

>> We here concentrate on discussions of UTC and Leap
>> Seconds, which is foundational, yet obviously "local time" is required
>> and there's nearly a complete lack of standards that govern it.
> I'm surprised to hear this. A "complete lack of standards", really? What, in your opinion, would a complete set of standards look like?

A) Define a comprehensive set of date and time related terms and 
definitions

B) Clarify TAI, UTC, and Leap Seconds specs including the "IERS 
reference meridian"

C) Provide a standard API or interface specification for automatic 
retrieval of the historic Leap Second record, announcements, and 
expiration.  (See Rob Seaman's DNS project as an implementation example)

D) Revise the time dissemination protocols in terms of these new definitions

E) Define the meridians for purposes of civil timekeeping (not 
navigation) as aligned to the IERS reference meridian

F) Define the primary 24 "timezones" as 15 degree divisions of meridians 
of the 360 degrees of Earth's circumference

G) Define the timezones as time offsets from UTC *time* - minus West and 
plus East of the IERS reference meridian

H) Define the "date line" as the transition from negative UTC offset to 
positive UTC offset time zones

I) Define a standard array of time zones as offsets from UTC time with 
standardized character names (needs to accommodate those odd +13:00 and 
+14:00 timezones) (probably also wants a fixed UUID class identifier for 
each)

J) Define exactly how the UTC counting mechanisms are reflected on, or 
accrued to, local timescales

K) Define exactly what is meant by Daylight Savings and how the 
transitions are applied to local time scales

L) Revise or replace ISO 8601 to provide a standardized character 
representation for precision timekeeping purposes that comprehensively 
supports the timezone offsets and Daylight including, perhaps, the 
TAI/UTC offset in effect.

M) Revise c language and POSIX time definitions to comprehensively 
support Leap Seconds and the definitions of local time (time2_t  ?)

N) Revise NTP and other time distribution systems to follow and support 
these new definitions and specifications, including Leap Seconds, and 
that requires specification for the dynamic update of historic, 
announcement, and expiration of Leap Seconds.

That may then provide the underpinnings for implementations to migrate 
to this more uniformly and comprehensively defined set of timekeeping 
specifications.

Along the way it would be helpful to be sensitive to cultures 
world-wide. For example, basing it all on the "Gregorian calendar" may 
not be such a good start - maybe the name should be changed.

Yeah, it looks like a tall order to accomplish all that, but if its not 
done the timekeeping community will continue to trash. Had this been 
started in 2000 instead of just blaming Leap Seconds we'd be done by now.

>> Fixing
>> Leap Seconds, either by more clearly defining it so implementations can
>> get it right (my very strong preference)
> What do you mean by "get it right"? Is there an error in the specification or is there a flaw in the implementation? Is there only one true implementation? When an implementation does not "get it right", is the root cause an error in the definition, or in the clarity of the definition, or something else?
Well, all the above.

I see the difficulties stemming from the very early simultaneous 
development of UTC and c language and POSIX. The TAI and UTC 
specifications were scattered amongst organizations that themselves were 
reorganizing themselves, while c and POSIX were laying the foundations 
for the emerging computer industry. It's nobodies fault, but the c and 
POSIX timekeeping mechanisms didn't match the UTC specs and there was no 
way to obtain the Leap Second information. At the same time there was a 
nearly complete lack of specification of timezones and local time, and 
the common practice traditions continued to morph into the tz database 
nightmare. The c and POSIX approach, flaws and all, found its way into 
nearly all platform implementations - OSs, languages, etc. This is a 
deeply embedded legacy issue which society needs to address, otherwise 
trouble with timekeeping will continue to plague modern civilization.

Mankind has sought to reconcile keeping accurate time with the sun and 
the heavens. Atomic science and modern astronomy made it possible to 
quantify the differences. TAI, UTC, and Leap Seconds are triumphs of 
modern science in the ancient tradition of timekeeping. In some respects 
the difficulties are just a teething problem - the technologies have not 
fully and uniformly taken up the science. This might not be surprising - 
the Gregorian calendar was not adopted in Turkey until 1933, 350 years 
after the calendar's establishment.

Surely modern technologies and engineering can overcome these 
difficulties. It is shortsighted and irresponsible to abandon 4500 years 
of the history of science by abandoning Leap Seconds merely for the 
convenience of implementation. I'm perplexed why so many expert 
timekeeping engineers would just throw up their arms in defeat. I see 
the effort as challenging, and so, fun.

>> or ceasing Leap Seconds (which
>> some hope will mitigate the problems but I believe will make it worse)
>> doesn't address the elephant in the room - local time.
> How would ceasing leap seconds affect your world of video time codes?

Basically, in much the same way it might effect every other timekeeping 
system. Today the TV systems are very precise (high quality frequency 
distribution) but not date/time accurate for reasons all timekeeping 
systems have flaws. The task is further complicated by the many media 
components, standards, and the peculiar x/1001 timebase in wide use. But 
the aspects of keeping accurate calendar and time are shared with all 
timekeeping systems.

-Brooks

> /tvb
> _______________________________________________
> LEAPSECS mailing list
> LEAPSECS at leapsecond.com
> https://pairlist6.pair.net/mailman/listinfo/leapsecs
>
>