-
Notifications
You must be signed in to change notification settings - Fork 0
/
RELEASE-NOTES.txt
225 lines (162 loc) · 9 KB
/
RELEASE-NOTES.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
Joda-Time version 2.0
---------------------
Joda-Time is a date and time handling library that seeks to replace the JDK
Date and Calendar classes.
This is the eighth release of Joda-Time.
This release contains enhancements, bug fixes and a time zone update.
We require JDK 1.5 or later as features such as generics are used.
It may be possible to use retroweaver to compile this under an earlier JDK but we haven't tried.
******************************************************************************
Compatibility
The change in major version indicates compatibility issues.
If your code just _used_ Joda-Time and had no deprecation warnings then this
release is fully compatible. Otherwise you need to read the detailed notes.
******************************************************************************
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://joda-time.sourceforge.net/related.html **
Enhancements since 1.6
----------------------
- Move to Java 5, with generics
See compatability notes.
- Add YearMonth, useful for credit card dates [1863090]
- Add MonthDay, useful for birth dates without year
- System clock can now be controlled by applications
DateTimeUtils.MillisProvider is now public
- Word based period formatters available in multiple languages [1252708]
PeriodFormat provides a resource bundle based language formatter
Currently supported (via online translators) are English, German, Dutch,
French, Spanish and Portuguese. Corrections and additional languages welcome.
- Static parse() methods available on all major types
These allow the formatter to be controlled
They do not always parse the same formats as the constructor taking an object
- Parsing of month and day without year now handles February 29th
This is achieved by changing the default year from 1970 to 2000 when parsing
a month or day without a year. This behaviour can be controlled using the new
withDefaultYear() setting on the formatter (set to 1970 for the old behaviour).
- Add static factory method millis() to Duration [2648777]
This checks for and returns the singleton value for ZERO
- Add methods to Duration to get standard minutes, hours and days [2862884]
- Support pluggable locale text and additional locales in JDK 6 [2690370]
Extra info accessed by reflection if JDK 6 used
- Better error messages for invalid time zone ids [2781835]
- Allow 'Z' and 'ZZ' in format patterns to parse 'Z' as '+00:00' [2827359]
- Add DateTimeFormatter.withZoneUTC()
Provides easy way to set UTC, which is often required for parsing
- Add DateTimeFormatter.parseLocalDate(), .parseLocalTime(), .parseLocalDateTime()
These parse the input string in the expected manner handing time zones and offsets.
For example, the LocalDate parse will parse any time or offset from the string, but
will completely ignore them when returning the actual LocalDate.
- Add LocalDate.toDate() [2465359]
- Add LocalDateTime.toDate()
This provides a direct conversion to JDK Date which handles DST and
time zone data differences
- Cache hash code in LocalDate
Enhances performance
- DateTime constructors without seconds/millis [1982629]
- DateTimeFormatter convenience methods taking an Appendable [2607923]
- Add @FromString/@ToString annotations from joda-convert
This does NOT require the inclusion of joda-convert at runtime!
- Reduce logging from ZoneInfoCompiler by adding a verbose flag
- Better Javadoc of DateTimeZone.default behaviour
Compatibility with 1.6
----------------------
Binary compatible - Not fully, see below:
Source compatible - Not fully, see below:
Deprecated methods removed:
- Chronology.getISO()
- Chronology.getISOUTC()
- Chronology.getISO(DateTimeZone)
- Chronology.getGJ()
- Chronology.getGJUTC()
- Chronology.getGJ(DateTimeZone)
- Chronology.getGregorian()
- Chronology.getGregorianUTC()
- Chronology.getGregorian(DateTimeZone)
- Chronology.getJulian()
- Chronology.getJulianUTC()
- Chronology.getJulian(DateTimeZone)
- Chronology.getBuddhist()
- Chronology.getBuddhistUTC()
- Chronology.getBuddhist(DateTimeZone)
- Chronology.getCoptic()
- Chronology.getCopticUTC()
- Chronology.getCoptic(DateTimeZone)
Apart from the removal of the deprecated methods above, everything else should be binary compatible.
Testing has included clirr, javap and manual testing of old files with new code.
If you find something that isn't binary compatible then please let us know, although it may be too late to fix it.
Any direct implementations of ReadableInstant or ReadableDuration are not source compatible.
This is because of the additional generics in Comparable.
Your code will be source compatible if you extended AbstractInstant or AbstractDuration.
This very minor source compatability change was deemed to be the best balance of the various
difficult options that generics offers.
As mentioned above, erasure ensures that this source incompatibility is *not* a binary compatibility.
Note that not all deprecated elements have been removed.
Some methods and classes have been retained simply because the potential pain of binary incompatability
is greater than the gain of removing the deprecations.
Serialization compatible - Yes
Data compatible - Yes, except
- DateTimeZone data updated to version 2010o
Semantic compatible - Yes, except
Previously, DateTimeZone.forID matched time zone names case-insensitively, now it is case-sensitive
Previously, parsing a string where only the month and/or day is present would use 1970 as
the base year. This failed to handle February 29th. The new behaviour is as follows:
If the parse includes a field with a duration between months and days inclusive and does not include
any field larger than months, then the default year is changed to the value of getDefaultYear() on
DateTimeFormatter, which is the year 2000 by default.
In effect, this means that a pattern "ddMMM" which would previously have parsed to dates
in 1970 will now parse to dates in 2000 unless further customised.
The old behaviour can be simulated by calling withDefautYear(1970) on the formatter.
Previously, calling various methods during a daylight savings overlap would change the offset.
Now, most methods (such as withMillis/withSeconds/withMinutes/...) will retain the offset wherever possible.
Previously, calling DateTimeZone.getOffsetFromLocal during a daylight savings overlap chose the
earlier instant in the Western hemisphere and the later instant in the Eastern hemisphere.
Now, it always returns the earlier instant (summer time) during an overlap.
This affects the constructor of DateTime and other methods.
Deprecations since 1.6
----------------------
- DateTimeFormatter.getChronolgy() [2783325]
Incorrect spelling - new method DateTimeFormatter.getChronology()
Bug fixes since 1.6
-------------------
- LocalTime.fromDateFields()
Now handles times based on java.util.Date before 1970
- LocalDate.toInterval() [2487417]
Now handles time zones which have no midnight at DST cutover
- DateTimeZone.convertLocalToUTC [3102760,2182444,2553453]
New method now retains the offset wherever possible during calculations
This affects higher methods like withHourOfDay/withMinuteOfHour/withSecondOfMinute/withMillisOfSecond
which now do not change offset when called within a DST overlap
- DateTimeZone.convertLocalToUTC [2903029]
Now handles date after last ever DST change
- DateTimeZone.getOffsetFromLocal [2952991]
The behaviour during DST overlaps is now defined to always return the earlier instant
which is normally known as daylight or summer time. Previously, the result varied by hemisphere
This affects the constructor of DateTime and other methods
- DateTimeZone.getDefault [3048468,3056104]
Handle missing user.timezone system property on Android that resulted in stack overflow
- Duration.toString
Fixed to work correctly for negative values
- Period formatting concurrency [2820871]
Fix possible concurrency hole in PeriodFormatBuilder.Separator
- Period formatter builder append(PeriodFormatter) did not handle some case [2495455]
If the appended formatter contained a separator as the first element, it failed
- Classloading CachedDateTimeZone could invalidate state [2935625]
Default time zone now lazily loaded
- DateTimeUtils shared static variable now volatile [2986043]
- DateTimeZone.forID(String) now case-sensitive
Previously, it was case-insensitive
- Handle broken serialization in other tools [3117678]
Some tools can't handle the joda-time stub serialization, kludge a fix for them
- Time zone compiler now handles 24:00 [2804258]
- Time zone compiler now handles non-UTC better
- Javadoc fix in Months [2721880]
- Javadoc fix in PeriodFormatterBuilder [3100939]
Feedback
--------
All feedback is welcomed via the joda-interest mailing list.
The Joda team
http://joda-time.sourceforge.net