��So I started looking into supporting the various formats provided by the
CLDR data, and promptly fell down a crazy rabbit hole.
It turns out that since I switched over to CLDR, DT::Locale has not been
handling the CLDR formats properly. While they're somewhat like Java
patterns, they're not quite the same, so some things were just broken.
A notable example is the "en" locale's full timee format, which right now
gives us the strftime format "%{hour_12}:%M:%S %p v".
That trailing "v" is an unhandled CLDR specifier.
The obvious fix is to just redo the pattern converter to handle the CLDR
patterns (see
http://www.unicode.org/reports/tr35/tr35-9.html#Date_Format_Patterns).
Unfortunately, these patterns include an element that makes this insanely
hard, which is that they have their own time zone names!
Basically they have _stable_ names for time zones, as opposed to Olson,
where names can change between releases.
A stable name is a "metazone", which is a set of time zones all sharing
the same rules, at least for some amount period in history. An example
would be the "America_Pacific" metazone, which currently includes a bunch
of active time zones (America/Los_Angeles, America/Vancouver) and less
active names (America/Dawson).
The metazones then have localized names in various lengths and
specificities. In English, the "America_Pacific" metazone can be written
as "Pacific Time", "Pacific Standard Time", "Pacific Central Time", "PT",
"PST", and "PDT". Then in Chinese it can be 太平洋标准时间 and a bunch of
other names.
To make things even more complicated, individual time zones can be part of
multiple metazones over the course of their lifetime, when the time zone
rules change.
This is all very complicated, and actually the rules for what exactly to
display are even more complicated than I've said so far. Sometimes you
have things like "Pacific Time (Canada)" or "United States Time (Los
Angeles)".
So the question is whether it's worth bothering with this. I'm kind of
tempted to just punt and simply display either a long TZ name,
abbreviation, or offset.
OTOH, it irks my sense of doing things right to do this.
I don't suppose any sucker^Wvolunteer wants to take on the project of
working on this?
As a side note, supporting the CLDR formats also requires extracting more
info from the XML files, for things like narrow eras and whatnot. This
isn't too hard, though, since it's just additional simple lists.
-dave
/*==========================
VegGuide.Org
Your guide to all that's veg
==========================*/
