forked from ThreeTen/threeten
-
Notifications
You must be signed in to change notification settings - Fork 0
/
TODO.txt
197 lines (177 loc) · 7.89 KB
/
TODO.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
/*
* Copyright (c) 2007-2012, Stephen Colebourne & Michael Nascimento Santos
*
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* * Redistributions of source code must retain the above copyright notice,
* this list of conditions and the following disclaimer.
*
* * Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* * Neither the name of JSR-310 nor the names of its contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
Simple tasks
------------
- Test min/max year for week-based-year. The max/min year is 999,999,999.
But the week-based-year may be 1,000,000,000. This needs testing.
The info will vary according to the WeekRules chosen, so will need to be a method on WeekRules.
More complex tasks
------------------
Utils
- MathUtils can't be public, can't put in java.math as we require JDK5 support
Duration
Instant
- improve toString/parse
- implement Calendrical?
Time scales (UTC/TAI)
Date/Time classes
- DateResolver rework - takes int or MonthOfDay or calendricals
- OffsetDateTime.toEpochSecs() could be private
- with(Calendrical) - need to figure out how
- remove ISO chronology from LocalDate etc classes
- try to remove DateTimeRuleGroup
- DateTimeFields.roll
? InstantProvider implementations toEpochMillis()
? getMonthOfYear() -> getMonth(), etc
? Calendrical rule for date/time as a period (for between calculations)
? MonthOfYear methods taking year, as well as boolean
Rules
- DateTimeField.from(Cal...)
- Change DAY_OF_MONTH.field(6) to DAY_OF_MONTH.of(6) - to act like factories, also period units
- ensure other calendar systems re-use ISO defined rules
- Handle case where values have gaps, eg 1,2, 4,5,6, 8
? parse()
? deriveInt for fields
? ISO era
? Remove WEEK_BASED_YEAR and WEEK_OF_ -> WeekRules
Date/Time formatting
- merger - general processing
- merger - days overflow
- merge ISO weekyear
- parse 24:00 - maybe a special end-of-day class?
- SPI for date-time text
- strict/lenient parse
? upper/lower case
- Arabic numbers have negative sign after number
- parseInto(Calendrical)
- default calendrical to pre-define era for example
- check compatible with RFC "Wed, 02 Apr 2008" and j.u.Date "Wed Apr 02 time zone 2008"
? substitute text (replacing built in text for Months/DOW etc)
Time zones
- Use WET/CET/EET as valid short abbreviations?
- SPI for zone names
- parse/format names
# some zones have transitions where only the name changes - America/Resolute
- aliases resolved at runtime not compile time
- test against TZDB binary data
? get region ids by offset (JDK method)
? Drop Etc (signs reversed), Older country based IDs
# (EST, MST, HST changed in 2005r - no longer observe DST - http://java.sun.com/developer/technicalArticles/Intl/alertFurtherInfo.html)
# (MET no longer Asia/Tehran, now Middle Europe)
# http://java.sun.com/javase/tzupdater_README.html
# http://java.sun.com/javase/timezones/tzdata_versions.html
# http://java.sun.com/javase/timezones/DST_faq.html
# http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5055567 and related
# JDK TimeZone.setDefault sets an inherited thread local
# Platform specific ids - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6534626
# Change zone info dynamically - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4701860
# Exception on bad zone - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4412864
Periods
- WIP branch, decide on normalization
- Between factories -> ? DAYS.between(date1, date2) - difference between epoch amounts in unit
- Formatting/parsing (defer?)
- Period.toString is not output of state
Matchers/Adjusters
- more general next/previous
? recurrences
Calendars
- HistoricChronology
- EthiopicChronology
- more calendar systems
- Coptic year definition
- plus/minus long vs int
JDK integration
- Proper integration into OpenJDK classes for providers
- Proper CLDR provider implementations
General
- Split Clock so only system implementation is in core?
- remove ArithmeticException from javadoc -> spec/overview
- cache todays date
- localized day of week number -> WeekRules
- get month/weekday text
- serialization formats
- evaluate hash codes
- check overflows
? factories/methods taking double - double is very unreliable
===============================================================================
Possible items
- roll()
- round() - truncateToSeconds() feels weird
- iteration
- era in the hash codes
- ModJulDays rule - BigDecimal
- IntValue interface, implemented by Number/Integer
- public factory for LocalDate.fromDayOfYear(year, doy)
- Optimise LocalDateTime plus/minus times by having a local plus(int,int,int,long,sign,LocalDate) method
- intervals (defer completely?)
- HalfDays period unit for AM/PM (more accurate than 12 hours)
- InvalidDateException - better exception name?
- simplify Clock to Calendrical, merging
Use cases
- Day of Olympiad (roughly four year period)
===============================================================================
Done
Document
- requirement: non JDK extensible
- null approach - nulls rejected except in isXxx() and in framework-level code
- type-safe where sensible
- many-headed problem
-- Zone - Local/Offset/Zoned
-- Precision - Y/YM/YMD/HM/HMS/HMSN/DateTime/...
-- Calendar - ISO/Julian/Coptic/...
-- FieldTypes - Y/M/D/H/M/S...
-- Periods - Y/M/D/H/M/S...
- Joda issues
-- Instant vs Partial
-- Partial with time zone
-- Not easily extensible
-- Chronology is complex
-- Date holding chronology is complex
-- Exposed long millis
- Parsing with wrong pattern letter case (month vs minute, doy vs dom) is caught
- Obtain leap-second rules from TZDB rather than a file
Not doing
- Use nanoOfDay rule in LocalTime factory - NO, as doesn't work
- toString(pattern)/parse(str, pattern) - NO, due to ease of formatter usage
- Add getAmPm() to time classes - NO, due to low use case
- Remove TimeSource replace by InstantProvider - NO, due to UTC/TAI
- don't use Local Mean Time - add a flag to the TZDB compiler to determine whether it uses
LMT or not. LMT is the estimated time before time-zones were introduced. The JDK removes LMT times,
and we should have a flag to do the same. Need to check exact way in which JDK removes LMT!
- NO, see email thread - unclear as to whether change is beneficial
- get rule by name - NO some rules are based on data
- get chrono by name - NO some rules are based on data
- Rename DateProvider to LocalDateProvider - NO, interface was removed
- Rename period classes - NO, current names seem fine
- Promote TimeDefinition to top-level type - NO, moved it to rule class instead
- date.with(RULE, value) / date.plus(amount, UNIT) - NO, because date.plus(UNIT.of(amount)) works well enough
- DateTimeAdjuster - NO, it adds more complexity