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

[roger riggs]

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
>