These are the release notes and advice for upgrading Joda-Time from version 2.2 to version 2.3.
Joda-Time version 2.3 --------------------- Joda-Time is a date and time handling library that seeks to replace the JDK Date and Calendar classes. This release contains enhancements, bug fixes and a time zone update. The release runs on JDK 5 or later. Joda-Time is licensed under the business-friendly Apache License Version 2. This is the same license as all of Apache, plus other open source projects such as Spring. The intent is to make the code available to the Java community with the minimum of restrictions. If the license causes you problems please contact the mailing list. ** Please also check out our related projects ** ** http://www.joda.org/joda-time/related.html ** Enhancements since 2.2 ---------------------- - Interval/MutableInterval .isEqual() [#20] Add method to compare intervals ignoring the chronology https://github.com/JodaOrg/joda-time/issues/20 - Chronology classes now define equals methods [#36] Previously, the Chronology classes relied on caching in factory methods to guarantee instances were singletons Now, there are dedicated, normal, equals methods This will aid weird cases where deserialization or similar avoids the caches It will make no difference to most users - Maximum size for pattern cache [#49] Sets a maximum size for the cache to avoid memory issues - Add LocalDateTime.toDate(TimeZone) [#48] Provides an alternate way to create a java.util.Date that avoids some synchronization - Home page moved http://www.joda.org/joda-time Compatibility with 2.2 ---------------------- Build system - Yes Binary compatible - Yes Source compatible - Yes Serialization compatible - Yes Data compatible - Yes, except - DateTimeZone data updated to version 2013d Semantic compatible - Yes, except - DateTimeZone is now limited to offsets from -23:59:59.999 to +23:59:59.999 - BasicChronology now defines an equals method This which would affect you if you subclassed it (unlikely) - GJChronology now has a minimum cutover instant of 0001-01-01 (Gregorian) Its unlikely you have it set earlier than this If you did your code was broken anyway Deprecations since 2.2 ---------------------- - DateMidnight [#41] This class is flawed in concept The time of midnight occasionally does not occur in some time-zones This is a result of a daylight savings time from 00:00 to 01:00 DateMidnight is essentially a DateTime with a time locked to midnight Such a concept is more generally a poor one to use, given LocalDate Replace DateMidnight with LocalDate Or replace it with DateTime, perhaps using the withTimeAtStartOfDay() method Bug fixes since 2.2 ------------------- - ZoneInfoCompiler and DateTimeZoneBuilder multi-threading [#18] A thread local variable was previously only initialised in one thread causing NPE https://github.com/JodaOrg/joda-time/issues/18 - Short time-zone name parsing failed to match the longest name This affected two short names where one is a short form of the second such as "UT" and "UTC" - Days.daysBetween fails for MonthDay [#22] Incorrect calculation around leap years - DateTimeZone failed to validate offsets [#43] Previously, there was little validation, resulting in the ability to create large offsets Those offsets could fail in other parts of the library Now, it is limited to -23:59:59.999 to +23:59:59.999 - DateTimeZone.forOffsetHoursMinutes failed to allow offsets from -00:01 to -00:59 [#42] The forOffsetHoursMinutes() method could not create an offset from -00:01 to -00:59 This was due to an inappropriate design A backwards compatible change to the input handling has been made forOffsetHoursMinutes(0, -15) now creates -00:15 - DateTimeFormatter.parseInto [#21] Fix parseInto() where it obtains the default year for parsing from the ReadWritableInstant Previously, the wrong year could be obtained at the start or end of the year in non UTC zones Now obtains the year from the ReadWritableInstant using the chronology of the ReadWritableInstant - Better thread-safety in ISODateTimeFormat [#45] - Fix GJChronology.plus/minus across cutover and year zero [#28] When subtracting a number of years from a date in the GJChronology there are two considerations The cutover date might be crossed, and year zero might be crossed (there is no year zero in GJ) Previously, each were handled separately, but not together. Now it is fixed As part of this change, the minimum cutover instant was set to 0001-01-01 (Gregorian) Scala -------- Joda-Time uses annotations from Joda-Convert. In the Java programming language, this dependency is optional, however in Scala it is not. Scala users must manually add the Joda-Convert v1.2 dependency.