Background and design notes

[jodastephen]

Just wanted to note that your background and design notes are well written and fairly comprehensive. I had a few minor points I wanted to make.

1. JSR-310 ended up going to considerable trouble to define a way around leap seconds. You've obviously found the details. Perhaps you could consider matching or referencing the "Java time-scale"? The definition was very carefully worded and it would be good to see other libraries build on its distinctive side-stepping of leap-seconds and ability to adapt to future changes/abolition.

2. In conceptual data types, I'd note that JSR-310 uses Period for date-based and Duration for time-based. Removing hours/minutes/seconds from Period greatly simplified the API, and you may find the same.

3. I personally think that choosing 100ns ticks is unfortunate although I fully understand the rationale. I've seen various complaints over the years about data read from databases (at 1 ns "precision") being lost when it is round-tripped via an application. This resulted in a 1ns precision in JSR-310 being a very hard requirement. It also matches much better increases in performance and accuracy that we should expect over the next 20 years. JSR-310 uses i64 seconds and i32 nano-of-second which was relatively easy to deal with mathematically (although I wish Java had a 96 bit or 128 bit primitive type). As a side note, if you do this, then a 1970 epoch makes a lot of sense as the epoch-second value matches classic Unix/Java.

4. It looks like you won't handle other calendar systems. This will simplify your API greatly, which JSR-310 could not do.

In summary, JSR-310 is a product of the Java programming language which does yield some additional complexity. The fields/units allow multiple calendar systems and formatting to work but add complexity, particularly the need to have an interface layer (the temporal interfaces exist for interoperation, not for user code).

As I believe you have identified, the key to a successful API is to represent the concepts of date and time in a compatible manner between languages. The details of methods, formatting, parsing and so on are very much where a specific language makes itself felt (although it would be good to try and match the algorithms for plus/minus in LocalDate and ZonedDateTime to aid developers porting code between languages).

Good luck!

[depp]

Wow, Stephen Colebourne commented on my design!

1. I feel a little uneasy making references to a time scale that lacks implementations on common hardware, although the Java time scale does make excellent trade-offs. A concern I have is that on hypothetical platforms where it is possible to report the current time according to the Java time scale, it may present problems when interacting with other systems running on the same computer, if those systems use a different time scale. I would rather promise to e.g. provide the same result as clock_gettime() on POSIX systems.

2. Interesting, I didn't notice that distinction. I may copy this.

3. I am very concerned about round trip integrity. The choice for a 64-bit timestamp may have been driven partially by a fondness for small data types, round trip integrity is more important. Thanks for bringing this to my attention.

4. Omitting calendars other than the ISO-8601 calendar was a only scoping decision for version 1.0, although I doubt there will be much demand for it.

Thanks for your input.

[jodastephen]

Just to note that the problem with POSIX is that it is very ill-defined. What exactly does it do during a leap second? With the Java-time-scale / UTC-SLS you know what it should do, and thus it moves to being an implementation problem from a spec problem.