[LEAPSECS] Focus in the debate, alternative proposal

Magnus Danielson magnus at rubidium.dyndns.org
Fri Jan 7 10:42:45 EST 2011


On 01/07/2011 01:54 PM, Ian Batten wrote:

>

> On 7 Jan 2011, at 00:28, Poul-Henning Kamp wrote:

>

>> In message <47D3BBA6-A381-4DAD-AD56-08E2B40FDF37 at PIPE.NL>, Nero Imhard

>> writes:

>>

>>> Each year should have at least two [...]

>>

>> Have you considered that in asia one of them is likely to happen during

>> the business day ?

>

> Summer Time shifts happen at 2am (or thereabouts) local, so that there

> are windows when the delta between adjacent timezones, even those

> following equivalent summer time rules, change. The world still turns.


UTC is an international time-scale free of any local concerns, and
leap-seconds is applied at the same time world-wide. This is why it is
"Universal". This is the value of the time-scale, you can use UTC
wherever you are and effectively interchange time-stamps in UTC between
every other and be able to interpret it correctly.


> When the leap second is applied is irrelevant for 24x7 operations. So

> the issue you raise only affects daytime only shops.


True.


> What stops leap seconds being applied at local 2am?


Then the systems needs to be tested for it to operate correctly. If it
could be sneaked in between working hours less systems would be
affected. However, those 24x7 systems would need to be fully tested anyway.

Adjusting every month would create a higher testing rate of the real
systems. Creating a lab-setup with even higher rate is possible when needed.

Increasing the adjustment rate (as Tom proposed) or adjusting any month
to minimize UTC-UT1 (as Rob proposed) would however not address the
concern that Poul-Henning has been pointing at, the need (in some
systems) for advance notice.

Then we have not even touched on the fact that some systems use
pseudo-continuous derivate of UTC, such as the POSIX time scale.

Moving leap-seconds out of POSIX (by switching POSIX from using UTC to
TAI) and handle leap-seconds through timezone files would still require
the same amount of advanced notice, but shift the testing somewhat, as
leap-second handling would still need to be tested such that shifts in
the timezone files tripples over for all parts of the system on the
correct time.

Cheers,
Magnus


More information about the LEAPSECS mailing list