[threeten-dev] Leap seconds and the Java time-scale

[roger riggs]

Hi,

Practically, I think the default is that Java time uses by the system clock
and does not modify its time keeping behavior.  The Java APIs are 
unaware of and do not
try to compensate for or correct to improve the accuracy, monotonicity 
or other
aspects of the system clock.  It might also be constructive to say that
the default Clock uses or stays in sync with System.currentTimeMillis.

Following the last leap year incident and NNTP glitches I think we 
concluded
that drift between java.time and System.currentTimeMillis
or the system clock would be counter productive in general and cause more
problems that it solves.

Roger



On 4/8/2013 11:57 AM, roger riggs wrote:
> Hi,
>
> I expect most developers to make optimistic assumptions and ignore the 
> odd cases.
>
> For those that care, they can implement Clocks that behave to meet the
> more detailed requirements.
>
> I would suggest allowing the Clock to throw an exception in the case 
> where it is
> not monotonic; that's the most likely application assumption that is 
> likely to
> cause bugs.  Either the application can handle it or at least not 
> proceed.
>
> Roger
>
> On 4/8/2013 11:22 AM, Douglas Surber wrote:
>> At 03:25 AM 4/7/2013, Stephen Colebourne wrote:
>>> On 5 April 2013 20:59, Douglas Surber <douglas.surber at oracle.com>
>>> wrote:
>>>> Given the lack of requirements for a clock it would be useful to
>>> add
>>>> some methods that characterize the clock.
>>> I guess that the API you suggest is feasible, but I'm not sure when
>>> users would use it. My feeling is that users won't be iterating
>>> around
>>> a list of clocks to find one with particular characteristics,
>>> instead
>>> there wil simply be a decision during coding time to chose one.
>> Agreed but they might code differently depending on the properties of
>> the clock. For example, it may be possible to use a quick simple
>> algorithm with a monotonic, high precision clock but necessary to use
>> a more complicated, slower algorithm with a possibly non-monotonic or
>> low precision clock.
>>
>> At some level an implementation must specify these properties of each
>> Clock. They can be human readable via JavaDoc or machine readable.
>> Making them machine readable will insure that every implementation
>> specifies them in a well defined way. It incidentally makes the
>> information available to code.
>>
>> This is not a high priority item, but I think it is at least worth
>> considering.
>>
>> Douglas
>>
>