These are the release notes and advice for upgrading Joda-Time from version 2.3 to version 2.4.

Joda-Time version 2.4

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   **
** https://www.joda.org/joda-time/related.html **

Enhancements since 2.3
- Duration.multipliedBy(), .dividedBy(), .negated()
  Additional methods on Duration

- LocalDate.hashCode()
  Remove unnecessary volatile on instance variable [#68]
  LocalDate hash code meets criteria of the racy single-check idiom

- DateTimeParserBucket
  Allow bucket to be re-used on a single thread [#111]
  Potential for performance improvements due to lower garbage churn
  Improvement only of interest to applications willing to write specialist code

- Support CharSequence throughout parsing
  Ensure that CharSequence can be used in parsing [#111]
  This can only be accessed by creating a mutable DateTimeParserBucket
  The bucket is a low-level construct for advanced use cases
  Potential for performance improvements due to lower garbage churn
  No API change

- Support Appendable throughout printing
  Ensure that Appendable can be used efficiently in printing [#120, #121, #122]
  No API change

- Increased performance of chronology lookup [#126,#105]
  No API change

- Increased performance of formatter lookup [#127,#129]
  No API change

- Increased performance of symbols lookup [#143]
  No API change

Compatibility with 2.3
Build system - Yes

Binary compatible - Yes

Source compatible - Yes

Serialization compatible - Yes

Data compatible - Yes, except
 - DateTimeZone data updated to version 2014e

Semantic compatible - Yes, except
- DateTimeField duration fields have been fixed
  For example, yearOfEra() now has a range of eras() rather than null
  The DurationField instances now compare using equals() correctly
- MutableDateTime.add(DateTimeFieldType,int), addDays(int) and friends [#77]
  Adding zero will no longer change the offset during DST overlap in autumn/fall

Deprecations since 2.3

Bug fixes since 2.3
- DateTimeField.getDurationField() / DateTimeField.getRangeDurationField() [#92,#93,#95]
  Previously some of the complex cases were wrong, notably around centuries and eras
  For example, yearOfEra() returned a range of null when it should be eras()
  A slew of tests were added and a variety of bugs fixed
  This affects DateTimeField.getDurationField() and DateTimeField.getRangeDurationField()

- Fixed another edge case in conversion from Local to UTC  [#76]
  The DateTimeZone.getOffsetFromLocal() method was fixed to handle the last cutover
  in DST history correctly.

- Period construction during DST overlap [#156]
  When creating a period, if one end is within a DST overlap and one beyond the overlap
  then the calculated period was incorrect.
  The calculation has been changed no ensure no extra hour is added.

- DateTimeUtils.isContiguous(ReadablePartial) [#89]
  The isContiguous() method could throw a NullPointerException when evaluating weird partials

- Period.normalizedStandard(PeriodType) [#79]
  Fix handling of PeriodType when either years or months missing

- Partial.with(DateTimeFieldType,int) [#88]
  Validation in this method was not as thorough as that in the constructor
  This allowed invalid partials to be created

- MutableDateTime.add(DateTimeFieldType,int), addDays(int) and friends [#77]
  Adding zero to a MutableDateTime used to change the offset during DST overlap in autumn/fall
  This is now fixed to not change the offset

- DateTime/MutableDateTime constructors taking millis now validate [#100]
  Previously, new DateTime(Long.MAX_VALUE) would be accepted, now it will be rejected
  This ensures that the maximum/minimum year are respected

- Ensure isLeap() returns correct result for day fields [#110]
  Day-of-month and day-of-year fields should report leap days

- Insist that year > weekyear when creating Partial [#96,#98]
  As these compare equal code previously allowed either order

- Handle weird TimeZone implementations with null ID [#133]
  Calling DateTimeZone.forTimeZone() would break if the ID was null

- Handle broken Android implementations better [#103]
  Apparently some Android implementations throw ClassCastException when comparing different types
  Thats dumb and wrong but the change to handle it is harmless

- Better concurrency in parsing [#101]

- Better Javadoc for parsing of numbers in format patterns [#60]

- Remove uncaughtException calls [#59]
  Previously the code called ThreadGroup.uncaughtException() which was invalid

- Fix Javadoc for ReadableDuration [#137]

- Fix the links to the IANA time zone database [#83]

- Better Javadoc for thread saefty of DateTimeUtils [#67]

- Better Javadoc for DateTimeComparator [#73]

- Better Javadoc for DateTimeFormatter parsing [#78]

- Better Javadoc for DateTimeFormat fraction of second [#62]

- Better Javadoc for DateTime toString and parse [#142]

- Better Javadoc for formatters that only parse [#97]

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.

Back to top

Version: 2.10.2. Last Published: 2019-05-09.

Reflow Maven skin.