[LEAPSECS] Standards of time zones -Brooks Harris

[Brooks Harris]

Hi Steve,

Thanks very much for the information.

First let me say I'm a very strong advocate of retaining Leap Seconds in 
UTC. When I first heard the idea that they be eliminated I was dismayed. 
Rather than abandon Leap Seconds, why not use the energy and resources 
to improve the standards and more fully inform the community how to use 
them. I'm very much in Rob Seaman's camp, I think, as he explained 
earlier - A Proposal to Upgrade UTC (rather than to degrade it) 
http://iraf.noao.edu/~seaman/leap/ <http://iraf.noao.edu/%7Eseaman/leap/>.

My guess is that UTC Leap Seconds will ultimately be retained because 
there is far too much disruption by a change like that. At the same 
time, improvements to UTC, dissemination of the information, and 
education are needed. If it worked better there won't be this pressure 
to abandon it.

I think there are several missing pieces to the puzzle. Perhaps first 
amongst them is a standards or engineering guidance document that 
clearly explains the terms and relationships related to time, calendar,  
and UTC.

The technical descriptions of, and responsibilities to, UTC are spread 
amongst several standards bodies ( BIPM, IERS, ITU ). This creates 
something of a maze to understanding UTC. Contributing to the challenge 
is the many unofficial explanations of UTC, each from different points 
of view, with their own terminology, and not all are credible. And UTC 
is only part of the general problem of implementation, since we soon 
encounter "time zones" and "daylight", and a host of related 
technologies like Unix-time/POSIX, NTP, PTP, etc.

One historic fact I see contributing to the difficulty is the 
unfortunate divergence between the developing time-keeping technologies 
behind the emergence of UTC (atomic time, astronomical observation), and 
the computer time-keeping technologies.

This divergence is understandable, since UTC was developing at the same 
time as computers and the computer industry had their own practical 
requirements. The subsequent standards efforts (especially the 
c-language and POSIX specs) naturally and necessarily continued to 
support the behavior of the installed base, inhibiting the development 
of more accurate specifications. Meantime, continued refinement and 
political developments around UTC were ongoing. Through all this there 
has been is a lack of clarity in the standards resulting in much 
misunderstanding and in-interoperable systems.

Everyone knows there are problems and everyone wants to solve them. I 
think today we stand near some solutions. Some parts are very much 
improved, like IANA's consolidation and management of tz database and 
the ICU project. Timezone Service Protocol draft 
(http://tools.ietf.org/html/draft-douglass-timezone-service-08) looks 
hopeful in providing  standard means of obtaining time-related metadata.

Unfortunately there are many uncoordinated efforts underway to solve 
particular problems, like Google's "smear" strategy. Sure, they need 
that in the present environment, but it does a disservice to the 
development of *accurate* time-keeping. Meantime the many OS venders 
(Apple, Microsoft, the many flavors of Unix and Linux, mainframe OSs, 
mobile OSs), DBMS systems and languages all take their own paths. I 
believe this is not so much a consequence of proprietary competition or 
other evil intent but the practical consequence of building systems in 
the absence of clear definitions of the fundamentals from some central 
authority.

We'd like to see convergence on a universally agreed upon design, but 
for this to occur there needs to be more consolidation and refinement of 
the relevant specifications. My experience is no doubt similar to 
everyone else's - wading through the standards is a career and, in the 
end, whole parts of the puzzle are just nonexistent. Great.

OK, well then, can we do something about that? We can't just complain 
about it. Might it be possible to mount an effort to write and 
standardize a consolidated specification and/or guideline which could 
serve the entire field better, helping lead to a more unified 
time-keeping industry? Maybe.

Who, or what standards body, would have the (international) authority to 
be taken seriously? I'm not sure about that, but since the whole 
time-keeping mess was started out by astronomers I figure this list is a 
good place to ask :-)

What I'm thinking about is illustrated by ISO 8601. Famous for defining 
representations of date and time, 8601 also defines important 
fundamentals - terms, "time units" and the Gregorian calendar. This is 
*huge*, it seems to me, arguably more important than its 
"representation" aspects. The history of the Gregorian calendar takes 
you back to Julius Caesar, Pope Gregory, the Reform, and the common era. 
Facinating, but all I want to do is *implement it*. And with 8601 I can 
stop right there - its has an air-tight modern definition of the 
Gregorian calendar. Done.

Without 8601 the many implementations of POSIX time algorithms (gmtime() 
in particular) would likely not produce the same results. In fact, as we 
know, some lesser implementations *do not* produce the same results - a 
dangerous fact. The gmtime() calculation is deceptively tricky, a topic 
that has produced an awful lot of discussion and misunderstanding 
amongst some colleagues I'm interacting with.

Next you need to deal with Leap Seconds, and you find yourself in the  
BIPM-IERS-ITU maze (yes it makes sense, but its not very clear how 
without a lot of study). Then comes "local time", or "civil time", and 
the standards trail goes cold. I find myself studying the "International 
Meridian Conference" (not its proper name) of 1884 in search of the 
standards provenance of "offset from UTC". But answers on this forum 
confirms my fear - it just doesn't exist.

So I ask your opinion(s) - Do you think there's a need for a document 
like I've described? What standards body do you think would be receptive 
to the idea? Or is it a fool's errand?

-Brooks




On 2014-01-07 03:43 PM, Steve Allen wrote:

> On Tue 2014-01-07T15:22:14 -0800, Brooks Harris hath writ:

>> I fully understand time zone specifications are fractured. My

>> objective is to determine what standards are most relevant

>> currently, that is, what standards may be considered "in force". And

>> where none exist, to state some sort of rules of "common use" or

>> "common practice" without referring to the impossibly large

>> collection of local jurisdictions and laws.

> Those local rules are the rules.

>

> The IANA tz community is the place where the folks who track the

> history and ongoing changes to those rules do their best-effort

> collaboration, and the rest of the world who rely on tz owe them deep

> gratitude for taking the trouble to do so.

>

> IMHO, the tz community has adopted a viewpoint which is pretty much

> that timezones are whatever the people who live somewhere do to their

> clocks, and sometimes that is contrary to the existing legal

> framework, but even if so that still qualifies as a timezone.

>

> Getting back to the topic of this list (leap seconds and UTC), in the

> proceedings of the two Future of UTC conferences

> http://futureofutc.org/

> there are several papers taking closer looks at the legal basis by

> which those timezones are based on GMT or UTC.  Again, in many places

> it is not clear whether the law chooses between those two.

>

> Aside from that, my impression is that most of this query is better

> answered in the context of the tz mail list than by LEAPSECS.

>

> --

> 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 95064http://www.ucolick.org/~sla/      Hgt +250 m

> _______________________________________________

> LEAPSECS mailing list

> LEAPSECS at leapsecond.com

> http://six.pairlist.net/mailman/listinfo/leapsecs

>

>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://six.pairlist.net/pipermail/leapsecs/attachments/20140108/ecb324df/attachment.html>