JDK 8 includes JSR-310, a new date and time library. But what about functionality that didn't make it into the JDK?
ThreeTen-Extra
The main ThreeTen project is now essentially complete. The project was developed and delivered via JSR-310 into OpenJDK and JDK 8.
However, as part of that process, certain pieces of functionality were rejected and/or excluded from the JDK. This was sometimes due to scope management and sometimes due to whether something was appropriate for the JDK.
The TheeTen-Extra project provides a home for that functionality.
ThreeTen-Extra is a project on GitHub that provides additional functionality. It is delivered via Maven Central and is dependent on JDK 8.
The following functionality is currently provided:
DayOfMonthtemporal value typeDayOfYeartemporal value typeAmPmtemporal enumQuartertemporal enumYearQuartertemporal value typeDays,MonthsandYearsamount value types- Next/previous day adjusters that skip the weekend (Saturday/Sunday)
- Coptic calendar system
- Support for the TAI and UTC time-scales
The project has spare space to add more functionality, so long as it is generally applicable. For example, additional calendar systems would be a good fit. Feel free to raise a pull request with your ideas.
Summary
The ThreeTen-Extra project is now available, providing an additional jar file of date/time code that builds on java.time (JSR-310) in JDK 8.
Comments welcome!
A weekend isn't always Saturday/Sunday.
ReplyDeleteIn Israel it is Friday/Saturday and Sunday is the first working day for example.
Agreed. But providing a Sat/Sun method is a reasonable place to start...
DeleteWhy JDK 8 doesn't have so common classes, for example: Days, Months, Years? Why did they rejected or excluded?
ReplyDeleteJDK 8 has the Period class, which can store an amount in days, months and years. There is less need for a class that can only store months.
DeleteStephen Colebourne, could you answer me? Did you reject Days, Months, Years utilities classes? Or other members of JSR was done this.
DeleteThe classes were removed years ago as they turned out to be an impractical design for the API given the limitations of the Java language. I made the removal and still agree with it. The JDK does not need those three classes (as it has the Period class instead), but they are useful for an external library.
DeleteAny chance something like TAI / GPS will make it into future versions of JSR-310?
ReplyDeleteI think Oracle would have to be pushed by a big paying customer for that to happen at this point. They want to keep the date/time API of a reasonable size and see TAI/UTC as non core.
DeleteHi Stephen, I'm glad to see this new date/time model in Java. Have you read the paper "A point based model of the Gregorian Calendar" ? http://www.sciencedirect.com/science/article/pii/S1477842405000424
ReplyDeleteIt has the same abstractions that you propose and more, like TimeLineFilter, relative dates, etc. It is implemented in Smalltalk as open source project called Chalten (http://smalltalkhub.com/#!/~HernanWilkinson/Chalten) and supports other calendars as well and it is based on a measure model that allows you to represent any type of time measure like 10 days, 3 weeks or 100 years, etc.
If you want the paper let me know, I was one of the authors :-)
Thanks for the links. I haven't read the paper. Perhaps you could send a copy? scolebourne/joda/org
DeleteIs there an extra-package that can be used with threetenbp 1.0 for Java 6?
ReplyDeleteThe project is here https://github.com/ThreeTen/threetenbp-extra however it is out of date and has not had any releases.
DeleteThank you for this, but unfortunately it won't compile with threeten 1.0 and Java 6. So no extras for me, unfortunately.
Delete