[threeten-develop] ThreeTen status

[Stephen C. <sco...@jo...>]

To explain where ThreeTen is overall, I thought it was best to write a summary.

Basically, there are two sides to the status of project. There are
parts I think are really successful and parts where my gut tells me
something is wrong. It is because of the latter that I haven't pushed
forward faster.

The good parts:
- the user-level date classes (LD, LT, LDT, OD, OT, ODT, ZDT,
ZoneOffset, ZoneId). These really do model the world of time, each
have a distinct API (so can't be merged), and map well onto what XML
does and what SQL should do.
- the time-zone package. I believe the internals here are really good.
The design copes with all the requirements I can see and is hugely
powerful without being troublesome to users.
- the split out of real UTC and TAI from the main API (although the
print/parse is troublesome)
- Instant and Duration (although they are constrained by the lack of a
96 bit primitive)
- the formatter design (closely modelled on Joda-Time)
- the conceptual split in parsing between parse and interpretation of data
- the basic model of date-time rules, where the rules can be used to
obtain additional data
- the idea of the WeekRules class

The OK parts:
- the enums, such as DayOfWeek and MonthOfYear. These are now closely
linked to ISO, which I tried to avoid, but in the end it was the best
design.
- periods. The design is OK, but in some ways it feels too much power
is exposed, and in some ways not enough.
- date-time rules as subclass of calendrical rules. This does work,
but occasionally feels weird.

The bad parts:
- the engine for merging date/time and deriving one piece of data from
another. This has always been complex. The current arrangement is just
about workable, but it doesn't feel ideal.
- the other calendar systems. These shoud really be quite easy to
write if the design is sound, but they feel complex to write.


Thus, I keep on looking to find a way to write the internals of the
engine/rules better. The task they have is to allow the extraction of
one piece of date-time information from one or more other pieces. For
example, extract the day-of-year from a year, month-of-year and
day-of-month. This is further complicated by invalid dates (31st
April) and by potentially invalid values (like interpretting a time of
10:70 as 11:10). A related problem is that the engine/rules should
support setting values - for example the equivalent of Calendar.set
(or add/roll). This seems to be hard using the current engine/rules
design.

Use cases (framework based):
- merge individual fields that have been parsed (without permitting
year-minute-day to be merged to a date, like the JDK does)
- allow factories on classes that merge arbitrary objects, such as
LocalDate created from a Year & MonthDay, or DateTimeField of year,
MonthOfYear and DateTimeField of day
- extract a date-time object from another date-time object, for
example extract LocalDate from ZonedDateTime
- set/add/roll

The current engine/rules design is based around the real classes. This
results in a lot of object creation and code around objects.

Simpler designs tend to pollute the user-level API (for example, you
could add a getZoneId() method to LocalDate that returned null, but I
reject that as horrible for users)

The longrules branch is my latest experiment to try a different
approach. It is trying to emulate Joda-Time more by having the core
engine/rules only operate on primitive numbers, not classes, treating
the problem more like straight maths. So far, this does seem neat, but
it is slower for most usages (although memory usage is lower for
dates). Part of the approach is to use a "packed date", where the
year-month takes the top 59 bits and the day-of-month is the bottom 5
bits to aid performance in common cases.

Do people like the primitives-based longrules approach? Or the OO
class based one? This "internals" problem is the biggest roadblock to
a successful JSR-310.

Stephen