Re: [threeten-develop] JSR 310: Date and Time API

[Stephen C. <sco...@jo...>]

The correct mailing list is thr...@li...

On 8 November 2011 11:49,  <jit...@ac...> wrote:
> 1) There are functions such as shown below public Duration minusNanos(long nanosToSubtract) {
>
>  Which do not have a check for NaN or a divide by zero error. Though this could be run-time, there are high chances that an absence of a throws or a try-catch can cause issues. We might want to have a look at it.

There is no division in the method you reference, and no use of
double, so the errors you describe are not possible. Even if they
were, ArithmeticException would be the correct error.

> 2) I was wondering if we could make our Date Conversion functions smart enough to retain and convert dates ( based on the flag parameter).
>
> I propose that we add a function parameter in any of our date conversion functions..say smartConvert . If this is set to true , we will convert the date
> Or obtain the date processing results in such a way that we get the most accurate of results.

In general, flag parameters should be avoided, as they are less
readable. In this case, the mechanism you describe would be quite
application specific. JSR-310 needs to provide the core functions and
extension points to allow the calculation you describe to be created
manually be a developer. In the case you describe, it is essentially a
rounding question, and JSR-310 may add some rounding functions.

Furthermore, you propose retaining "hidden accuracy" information.
Storing hidden information is something I strongly reject as it makes
working with an API a lot harder and more difficult to debug, as two
objects that look similar can do different things.

Stephen