In message <42F38D33.3050604_at_edavies.nildram.co.uk>, Ed Davies writes:
>Poul-Henning Kamp wrote:
>> 3. There is no way in hell we can prevent applications
>> of the two kinds from interacting.
>
>Yes.
>
>> 4. It follows therefore logically that any kind of rubber seconds
>> will introduce a new interface across which time will have to
>> be translated from rubber to SI seconds.
>
>No. Applications using UTS are presumably ones which don't
>care that much about exact time relative to TAI or whatever
>so translation is not necessary. E.g., if some application
>writes logfile timestamps in UTS but some other application
>reads and interpretes them as UTC it doesn't really matter.
>Mostly it'd just be a case of comparing the times anyway.
>
>Granted, there could be problems with different sources of
>information (e.g., logfile entries vs filesystem time
>stamps).
So you agree that introducing UTS would open the window for a new
class of problems.
Given that, UTS had better bring a fix for a problem which is much
worse, but it doesn't do that either.
The problem with leap seconds is not the 1 second jump, the problem
is *when* the jump is. UTS still suffer from the same thing:
some systems have heard about the leap second and some havn't.
Therefore it follows that adding UTS to the mix, just means that
there is yet another possible way leap seconds can screw me up when
I get a cable connected to an Acme Inc WizMagic device.
>When it contacts an NTP server
>it's got a choice: jump the clock (potentially non-monotonic)
>or steer the rate (rubber seconds).
Right, so we agree that UTS is not a solution to the leap second
problem, at best it is a dangerous hack to avoid application
from choking on the ...:59 second rerun or a more correct ...:60
implementation.
>> QED: rubber seconds in any shape or form will only make the problem
>> worse and not better.
And therefore this conclusion still stands...
>>>Please note that I'm not suggesting that rubber seconds
>>>are good in all cases: just that there are some
>>>circumstances where they are acceptable and, maybe,
>>>preferable to having non-monotonic times or times like
>>>14:59:60.
>>
>> There is nothing non-monotonic about it.
>
>This depends on the implementation, I think.
Right, and anything POSIX compliant implements this broken.
The fact that POSIX is "fixed" by abandonning leapseconds counts
heavily on the credit side of the cost-benefit of the proposal
because that fixes UNIX, MVS and Windows with one stroke of the
pen.
If on the other hand leapseconds are retained, we need to fix POSIX,
rather than keeping adding weird bandages over the mistake.
>> We just need (much!) longer notice about when it happens
>> to handle it properly in computers.
>
>Or an adequate way of getting the information to those
>systems which require it.
That's not really an "Or", that's an "And".
The "adequate way" is the operative word.
Getting leapsecond info to hardware after deployment is not possible
for 90% of all computing devices with clock facilities and with
1 cm^3 a lot of devices will have better than 1sec timekeeping
but no connectivity in the future.
So being able to deploy the hardware with a table of future leapseconds
that stretch into the credible lifetime (50 years) would work.
Pretty much nothing else will.
> http://www.edavies.nildram.co.uk/dns-leapseconds/
That's a nice InterNet centric idea, it just doesn't solve any
problem for anybody, NTP already has the option of passing the
information along to IP connected hosts.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Fri Aug 05 2005 - 10:14:26 PDT