Stephen Scott said:
> The basis of my understanding is that UTC is a timescale that:
> - progresses at a rate of the second (SI) and has done so since
> 1972-01-01.
> - is expressed as a count in the form of date, hours, minutes and
> seconds;
> - is continuous other than the discontinuities resulting from leap
> second corrections;
No.
It is continuous at all times. However, a UTC minute can be 59, 60, or 61
seconds long.
Thus at the end of June the UTC count may go:
--06-30 T 23:59:57
--06-30 T 23:59:58
--06-30 T 23:59:59
--07-01 T 00:00:00
--07-01 T 00:00:01
--07-01 T 00:00:02
or it may go:
--06-30 T 23:59:57
--06-30 T 23:59:58
--06-30 T 23:59:59
--06-30 T 23:59:60 (a positive leap second)
--07-01 T 00:00:00
--07-01 T 00:00:01
--07-01 T 00:00:02
or it may go:
--06-30 T 23:59:57
--06-30 T 23:59:58
--07-01 T 00:00:00 (a negative leap second)
--07-01 T 00:00:01
--07-01 T 00:00:02
(though the last of these has never happened yet).
> - is currently the basis for most local timescales;
Right, which is why changing its meaning is seen as the most efficient way
of changing lots of national times.
> With the replacement of some synchronous signal technologies by packet
> switched signals there is a desire to replace or supplement traditional
> reference signal distribution with a system that is based on a global
> time reference that can be used to generate timing reference signals at
> the point of use. The diminished central control over the management of
> discontinuities in the time references places an increasing importance
> on the deterministic nature of these time references.
There's no discontinuity in UTC itself. Thus it suffices for what you
require.
*HOWEVER*, if you represent the time as YYYY-MM-DD T hh:mm:ss *AND* don't
have a way of representing ss == 60, you have a problem. Similarly, if you
don't have an accurate list of leap seconds, you won't know whether the
time should go 58-59-00, 58-59-60-00, or 58-00. This latter is the
distribution problem.
> _*Instantiation of leap seconds*_
> In a prior inquiry about leap seconds I had asked about the application
> of leap seconds to various local tines in the different time zones. I
> have searched for documentation on how the leap seconds are instantiated
> in local time zones around the world. There is a need for a standard.
> This is a reiteration of the request for information.
The situation is clear.
(1) Leap seconds happen in UTC as shown above; that is, at the end of the
day.
(2) In countries where local time is defined as an offset from UTC, it
happens at the same *UTC* time. Thus if your local time is UTC+3:30, then
the sequence for a positive leap second is:
--07-01 T 03:29:58
--07-01 T 03:29:59
--07-01 T 03:29:60
--07-01 T 03:30:00
--07-01 T 03:30:01
--07-01 T 03:30:02
> This question was raised because TF.460-6 specifies the leap second
> adjustment to UTC and the emission of UTC.
This is the statement that specifies (1).
> There does not seem to be any
> guidance for the application of leap seconds to local timescales for the
> timezones UTC+14 to UTC-12.
That's (2).
> There is the perception by some that the
> leap second should be instantiated globally at the same time as it is
> signaled by UTC. I looked in TF.460-6 but could not locate a definitive
> statement to this effect.
It wouldn't be in TF.460-6. It would be in the definition of local time in
that time zone. If the time zone is defined as UTC+3:30, then *BY
DEFINITION* the leap second happens at 03:29:60 local time.
> If this is the case then the leap second changes would be instantiated
> just before 9:00 (9 AM) local time in Tokyo (UTC+9) and just before
> 19:00 (7 PM) local time in New York (UTC-5).
Correct. Though a June one would be 20:00 local time in New York.
And just before 05:30 in the morning in India, and at 09:30 or 10:30 in
South Australia.
> These are just examples but
> in either case it would probably be disruptive to critical time keeping
> systems to have a time shift instantiated at these times.
There is no shift, just variable base arithmetic.
But this is one of the reasons for abolishing leap seconds.
> It's not just for television. The evolving application of packet
> switched technologies (for example Ethernet and the Internet) in
> television, financial, scientific, telecommunications, power generation
> and other industries is creating a growing demand for the availability
> of accurate and precise, but most importantly deterministic time
> references.
Something that is incompatible with the present arrangements for the
announcement of leap seconds.
> Notwithstanding the possibility of stopping leap seconds it is more
> important to:
> - have a deterministic procedure for instantiating leap seconds in
> each time zone and;
They already exist. The leap second happens at midnight UTC, whatever that
may be in local time.
> - similarly for standard time and daylight saving time shifts which
> understandably are under local governance
Then you need to persuade each local polity to define deterministic rules.
Some (e.g. the EU) have, but the general principle that a past legislature
cannot bind a future one makes it only present policy, not fixed for all
time. (See, for example, the way the USA changed their rules a couple of
years ago.)
> I believe there is no particular requirement to eliminate the leap
> second if their insertions are well and deterministically defined and
> communicated.
However, the devil is in the details. And there are some very troublesome
details involved here.
> It's not time that needs to be fixed, it's the standards or the lack
> thereof.
Sorry, but that's just wrong.
> What can this group do to:
> - Document local practices for instantiating leap second corrections
> to UTC.
Not required.
> - Promote a standard for instantiating leap second corrections in
> local time zones.
Not required.
> - Promote standards for the communication of all UTC time corrections
> including leap seconds and standard / daylight saving time shifts.
These exist. The much bigger problem is getting people to implement them
correctly.
--
Clive D.W. Feather | If you lie to the compiler,
Email: cl...@davros.org | it will get its revenge.
Web: http://www.davros.org | - Henry Spencer
Mobile: +44 7973 377646
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
http://six.pairlist.net/mailman/listinfo/leapsecs
