From the CLDR list:
There are a couple of cases where two fields are tied together in
availableFormats, and need to be handled specially. One is h/a, which we already
deal with. The other, which we don't deal with, is y/G.
This comes in to play with certain calendars, such as Japanese, that require an
era field. A client requesting a format string via the availableFormats data is
not going to know whether they are using the Gregorian or Japanese or Thai
Buddhist calendars. They will request something like yyyy or yy. For Japanese,
the appropriate format string for both of those is Gy.
It gets more complex. For date format strings, I might request yyyyMMMMdd or
yyMMdd. For the first, the appropriate Japanese string would be something like:
Gy年MM月dd日
For the second, the appropriate string might be:
GGGGGyy/MM/dd
to get the one-character abbreviated era names, e.g. "H17/04/16".
Right now, if a client requests yyyy or yy, they're not going to get an era in
the result even if the Japanese calendar is requested.
Here's a strawman proposal for discussion tomorrow:
If a client requests a format string containing a year, and all the
availableFormat strings with a year also contain an era, then silently include
the era as part of the result. We may need to modify this to something else if
the first approach doesn't work.
For calendars that care, we'd need to provide a separate set of availableFormats
that follow these rules.
