Is there any possibility of supporting joda-time Partial?

[manning]

Hi, is there any possibility that threeten-extra will be extended to support the Partial date and time functionality of joda-time? We use these classes in our CoreNLP package (https://stanfordnlp.github.io/CoreNLP/), where they're sort of vital in translating natural language into formal time and date expression, since many human language expressions are partial.

In principle, we'd be happy to upgrade from joda-time to java.time, but in practice, we've been stuck for a decade, and it doesn't seem like this is changing..... Thx!

CC: @AngledLuffa

[jodastephen]

A class like Partial would be a perfectly good addition to ThreeTen-Extra. I don't currently have much spare time however, but feel free to create a PR.

[jodastephen]

I would appreciate confirmation that #387 meets your needs before merging it.

[AngledLuffa]

Neat, thanks for looking into this! I will budget time to investigate this week

[AngledLuffa]

Thanks for working on this. I looking into what it would take to replace our usage of joda-time in CoreNLP with java.time and threeten-extra, and I there were two small shortcomings with it being a dropin replacement for our use of Partial. I put that through Claude, and it wrote up the following for me:

---

Thanks for picking this up — this is the one thing that has been blocking us.

Some context on the use case, in case it is useful for judging the API. I maintain
Stanford CoreNLP, whose SUTime temporal tagger is
built on Joda-Time. Nearly all of what it uses has an equivalent in java.time, but it
represents every underspecified date ("June 15", "the 1990s", "Thursday") as a
Partial, and the absence of an equivalent is why we are still on Joda-Time. So this PR
would let us drop the dependency entirely.

I built the branch locally and ported enough of our code against it to see where the gaps
are. The bulk of our usage maps over cleanly: by call count we use isSupported (~80
sites), get (~38), with (~26) and without (~19), and isSupported / getLong /
withField / withoutField cover all of those. Our custom fields (quarter-of-year,
decade-of-century, week-of-month) also work as TemporalField implementations, which I was
not sure would be the case.

Two things do not, and one of them looks like it might be an oversight.

getFields() is unordered, but toString() is sorted

Joda's Partial keeps its fields ordered from largest to smallest, and quite a lot of our
code depends on that. Determining the coarsest and finest field present is the basis for
how we decide the granularity of an expression, how we truncate one date to the precision
of another, and how we pad an underspecified date out to a resolvable instant.

PartialTemporal stores a HashMap and returns Collections.unmodifiableSet(fieldValues.keySet()),
so iteration order is unspecified:

Map<TemporalField, Long> m = new LinkedHashMap<>();
m.put(ChronoField.DAY_OF_MONTH, 15L);
m.put(ChronoField.YEAR, 2017L);
m.put(ChronoField.MONTH_OF_YEAR, 6L);
PartialTemporal pt = PartialTemporal.of(m);

pt.toString()    // Partial[fieldValues={Year=2017, MonthOfYear=6, DayOfMonth=15}, null]
pt.getFields()   // [MonthOfYear, Year, DayOfMonth]

The interesting part is that FieldComparator already does exactly the right thing — base
unit duration, then range unit duration — but it is only used to build the TreeMap inside
toString(). So the ordering exists and is simply not exposed.

Would you consider having getFields() return a SortedSet (or at least a set with
deterministic comparator order) using the existing FieldComparator? From the outside it
looks like a small change, and it would save every consumer that cares about field
granularity from wrapping each call site in a sort. It would also make getFields()
consistent with toString(), which currently disagree about what order the fields are in.

If there is a reason to keep the set unordered, an alternative would be to expose the
comparator publicly, so callers can sort without reimplementing the base-unit/range-unit
comparison and getting it subtly different.

No arithmetic

PartialTemporal implements TemporalAccessor rather than Temporal, so there is no
equivalent of Joda's withPeriodAdded or withFieldAddWrapped. We use both, though only in
a couple of places, and adding a period to a partial raises genuine questions about what
should happen when the period has units the partial does not carry — Joda's answer there is
not obviously the right one, and I would not want to argue it is.

So I am not asking for this, and we can implement what we need on top of the accessor. But
it is the other behavioural difference from Joda's Partial, and if the goal of #369 is to
give Joda-Time users a migration path, it is probably worth a sentence in the Javadoc saying
that the type is deliberately read-only. That would have saved me a little time.

Small notes

• query(TemporalQueries.localDate()) returns null on a complete year/month/day partial;
  resolve(ResolverStyle.SMART) first, then querying, works. That surprised me, though it
  may well be the intended behaviour.
• The branch builds and passes on JDK 21 once module-info.java is out of the way, for what
  that is worth.

Happy to test a revision against our migration if that is useful — we have a fairly large
body of partial-date behaviour to check an implementation against, and I would rather find
problems now than after it ships.