Thoughts on JSR-310
The JSR-310 API recently entered early draft review. Will Java get a decent date/time API at last? See for yourself at http://wiki.java.net/bin/view/Projects/DateTimeEDR1. My thoughts are summarized here.
Some parts look promising. The API uses immutable objects, which is good! It provides aptly named methods for all fields, for example
getYear, and for arithmetic, for example
Some parts are a bit complex, though. So is the subject matter, but still. Simple parsing and formatting seem to be a bit involved unless you can use one of the pre-defined formats. Ideally there should be toString and valueOf methods with format strings, simple and easy to work with for the basic cases.
There should be a common interface and comparisons/operations that take mixed types.
LocalDate should certainly be comparable with
LocalDateTime (pick midnight) and preferably with
ZonedDateTime as well (default time zone). Ideally the older types, at least
java.util.Date, should be usable as well.
Clock is documented as throwing
withZone. Why? Assume the (not uncommon) use case where a web application has users from all over the world and matches the active user’s time zone. Naturally it will not use the system time zone. In general I don’t like methods to throw
UnsupportedOperationException. If an operation is optional, push it down to a sub-class or use a different interface and make it clear what is available and what is not.
TimeSource, which seems to be intended for low-level operations, uses milliseconds according to the documentation. It could use nanoseconds instead or as well.
Instant itself has nano-second support, so the API in general is fine.
Last but not least, look into performance! Calendar is often a tight spot. Make the common operations, like construction and date arithmetic, run fast.