Support durations like "3 hours", "1 hour".
I had originally planned to put the new simple duration support that we've developed in CLDR into the DurationFormat. But I've been looking with Doug at the current DurationFormat, and how to work in what we want in terms of API.
The DurationFormat has the following characteristics.
It produces formats like "3 hours and 20 minutes ago", which are not so much durations as relative points in time.
It also formats durations like "3 hours and 20 minutes", but that API is not public.
It can also do "more than 3 hours and 20 minutes ago" (ie with "more" or "less"), but the API is also not public.
The data is table driven, but rather complicated, and limited to certain locales.
My conclusion is that there is a lot of useful material, but we need to keep it draft until we have a chance to figure out what to do with it. In particular, it isn't a good fit for the new simple duration support.
What we want for now is something simpler; single units, up to the caller to pick the scale (whether he/she wants days or seconds). So here is a sketch of what I'm going to propose, here for initial feedback.
Some time ago, we'd set up the general structure for MeasureUnits and MeasureFormat, and used that in Currencies. It has the structure:
MeasureUnit (eg Currency)
Measure = Number + MeasureUnit (eg CurrencyAmount)
MeasureFormat formats/parses Measures (eg CurrencyFormat)
I propose using that structure for these durations:
We define a TimeUnit as a subclass of MeasureUnit.
To create, you use a TimeUnit.getInstance method with one of the Calendar fields.
Unsupported fields (like ERA) throw IllegalArgumentException for now.
A Measure is a combination of Number and MeasureUnit.
I don't think we need a specific TimeUnitFormat
Once we move to Java 5, we should generify this.
We define TimeUnitFormat as a subclass of MeasureFormat.
The TimeUnitFormat has a NumberFormatter which is used for the numeric portion. That has a setter and getter.
The TimeUnitFormat can format a TimeUnitAmount like "3 hours" or "23.5 minutes". On parsing, it (logically) tries all of the available TimeUnits for that locale and returns a TimeUnitAmount (containing a TimeUnit).
(Xiaomei is doing the equivalent C++ side)
Thanks for taking the time to discuss this, I feel strongly about it and love learning more on this topic. If possible, as you gain expertise, would you mind updating your blog with more information? It is extremely helpful for me.