[LEAPSECS] Future time

[Clive D.W. Feather]

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: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646