Introduce day periods with appropriate translations

[MenoData]

CLDR 28 has introduced a new concept for supporting day periods (including new pattern symbols "b" and "B"). See also:

http://cldr.unicode.org/development/development-process/design-proposals/day-period-design http://cldr.unicode.org/translation/date-time-names#TOC-Day-Periods-AM-and-PM-

Time4J might introduce a new class DayPeriod which can act as ChronoFunction<PlainTime,String> and offer options how to get the concrete time span and i18n-translation for a given time of day.

[MenoData]

Some notes:

• Pattern symbol "b" stands for fixed day-periods (am, pm, midnight, noon) where the latter two are optional and fall back to am, pm if missing.
• Pattern symbol "B" stands for flexible day periods using any kind of code (for example: morning1).
• Time spans are formally in minute precision and mapped to codes per locale.
• Stand-alone forms are defined by CLDR and should be taken into account in formatting/parsing.
• Three text widths are supported: abbreviated, wide and narrow.
• The new class DayPeriod in discussion would implement ChronoFunction<PlainTime,String>.

[MenoData]

Note that the Ethiopian calendar (see #389) uses a special division of the day into day periods which is not offered by CLDR-data but should be taken into account here.

[MenoData]

Postponed to v3.12/4.9.

[MenoData]

A new method public Map<String, String> getTextForms() was added to class CalendarText in order to enable specialized access to dayperiod translations.

[MenoData]

Some preparations are done including i18n-resources, but again postponed to another release in order to release an important bugfix for HijriCalendar earlier.

[MenoData]

ICU seems to be willing to realize this feature, too but when? The realization was postponed several times, now scheduled to release 57.1. See also:

http://bugs.icu-project.org/trac/ticket/11872

[MenoData]

Starting with Zulu language, some ambivalent data (source CLDR) were detected which can defeat parsing of day periods in strict mode. This affects following languages: az, et, fa, he, hi, hu, mk, pt, si, tr, zh, zu (now corrected). It is a necessary requirement that translations of day period codes must be mappable in a unique way on codes and vice versa.

Needs more investigation and correction of data. About the correction of Zulu data, see issue #420

[MenoData]

About Chinese (zh): Some entries (下午 - in the afternoon) were mistaken instead of 中午 (noon),

[MenoData]

Although CLDR explicitly states that the fallback rules for dayperiods should be similar to AM/PM-rules, some data didn't follow those rules (using ABBREVIATED as fallback) but followed the standard rules (using WIDE-FORMAT or NARROW-STANDALONE as fallback). This has been corrected now for some languages (especially az, bs, et, he, mn).

Furthermore, the internal dayperiod element value is now allowed to carry more than one dayperiod code in order to allow ambivalent codes in first parse phase. If all parsed codes resolve to same and unambivalent am/pm-value in second phase then final time resolving can still be successful. This flexibility makes sense especially for parsing of NARROW dayperiod values.