Poul-Henning Kamp wrote:
> 1. It is agreed that there are applications for which
> rubber seconds are unsuitable.
Yes.
> 2. Any use of rubber seconds will therefore only be
> for some limited subset of applications.
Yes.
> 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).
> 5. You have just introduced yet another place where computers
> and people can and will get timekeeping wrong.
See above.
> 6. We are trying very hard to avoid interfaces where time can
> be messed up or confused.
But I don't think you can. E.g., consider a computer which
has not been able to contact an NTP server for a while so
hasn't got an accurate clock. When it contacts an NTP server
it's got a choice: jump the clock (potentially non-monotonic)
or steer the rate (rubber seconds). Different applications
would have different needs. Others would just want to know
elapsed times.
>
> QED: rubber seconds in any shape or form will only make the problem
> worse and not better.
Remember that UTS is not supposed to be a wonderful solution
to everything - just a practical way of improving systems
which run software which is not prepared to or doesn't want
to deal with leapseconds. In this sense, it'll make the
situation better than it is at the moment where different
non-leapsecond aware APIs deal with leapseconds in different
ways.
>
>
>>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. Are you
sure there an no systems which don't just repeat the
leapsecond? I thought some Unix implementations do
that but I'm not sure. That would be non-montonic:
23:59:58.75
23:59:59.00
23:59:59.25
23:59:59.50
23:59:59.75
23:59:59.00
23:59:59.25
23:59:59.50
23:59:59.75
00:00:00.00
> 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. I wrote a proposal on the
subject a while back but dropped it off my website at
the end of last year. I've just put it back:
http://www.edavies.nildram.co.uk/dns-leapseconds/
And yes, more notice would be a good idea, too.
Ed Davies.
Received on Fri Aug 05 2005 - 09:02:05 PDT