For most users, ordinary use of DateIntervalFormat does not need to create DateIntervalInfo object directly. DateIntervalFormat will take care of it when creating a date interval formatter when user pass in skeleton and locale.
For power users, who want to create their own date interval patterns, or want to re-set date interval patterns, they could do so by directly creating DateIntervalInfo and manupulating it.
Logically, the interval patterns are mappings from (skeleton, the_largest_different_calendar_field) to (date_interval_pattern).
A skeleton
The calendar fields we support for interval formatting are: year, month, date, day-of-week, am-pm, hour, hour-of-day, and minute. Those calendar fields can be defined in the following order: year > month > date > am-pm > hour > minute The largest different calendar fields between 2 calendars is the first different calendar field in above order. For example: the largest different calendar fields between "Jan 10, 2007" and "Feb 20, 2008" is year.
There is a set of pre-defined static skeleton strings. There are pre-defined interval patterns for those pre-defined skeletons in locales' resource files. For example, for a skeleton YEAR_ABBR_MONTH_DAY, which is "yMMMd", in en_US, if the largest different calendar field between date1 and date2 is "year", the date interval pattern is "MMM d, yyyy - MMM d, yyyy", such as "Jan 10, 2007 - Jan 10, 2008". If the largest different calendar field between date1 and date2 is "month", the date interval pattern is "MMM d - MMM d, yyyy", such as "Jan 10 - Feb 10, 2007". If the largest different calendar field between date1 and date2 is "day", the date interval pattern is ""MMM d-d, yyyy", such as "Jan 10-20, 2007". For date skeleton, the interval patterns when year, or month, or date is different are defined in resource files. For time skeleton, the interval patterns when am/pm, or hour, or minute is different are defined in resource files.
There are 2 dates in interval pattern. For most locales, the first date in an interval pattern is the earlier date. There might be a locale in which the first date in an interval pattern is the later date. We use fallback format for the default order for the locale. For example, if the fallback format is "{0} - {1}", it means the first date in the interval pattern for this locale is earlier date. If the fallback format is "{1} - {0}", it means the first date is the later date. For a particular interval pattern, the default order can be overriden by prefixing "latestFirst:" or "earliestFirst:" to the interval pattern. For example, if the fallback format is "{0}-{1}", but for skeleton "yMMMd", the interval pattern when day is different is "latestFirst:d-d MMM yy", it means by default, the first date in interval pattern is the earlier date. But for skeleton "yMMMd", when day is different, the first date in "d-d MMM yy" is the later date.
The recommended way to create a DateIntervalFormat object is to pass in the locale. By using a Locale parameter, the DateIntervalFormat object is initialized with the pre-defined interval patterns for a given or default locale.
Users can also create DateIntervalFormat object by supplying their own interval patterns. It provides flexibility for power usage.
After a DateIntervalInfo object is created, clients may modify the interval patterns using setIntervalPattern function as so desired. Currently, users can only set interval patterns when the following calendar fields are different: ERA, YEAR, MONTH, DATE, DAY_OF_MONTH, DAY_OF_WEEK, AM_PM, HOUR, HOUR_OF_DAY, and MINUTE. Interval patterns when other calendar fields are different is not supported.
DateIntervalInfo objects are cloneable. When clients obtain a DateIntervalInfo object, they can feel free to modify it as necessary.
DateIntervalInfo are not expected to be subclassed. Data for a calendar is loaded out of resource bundles. To ICU 4.0, date interval patterns are only supported in Gregorian calendar. @stable ICU 4.0
| |
| |
| |
| |
| |
| |