On Sun, 26 Jan 2014, Bill Moseley wrote:
I lost track of this and it came up again this morning. I'm not having a lot
of luck researching what should be done.
I see in
http://cldr.unicode.org/cldr-features#TOC-Locale-specific-patterns-for-formatting-and-parsing
there's a heading "Translation of Names"
where there's a list item "timezones, timezone cities" but no link.
But, perhaps a more on point and useful question is:
I need to always show times with a timezone, and in a way that is localized for
the user. What is the best way to do that currently with
DateTime?
Should "EST" be translated? What about "UTC"? (e.g. if using UTC + offset)
I suspect UTC + offset isn't a very friendly timezone for many
people.
Locale "ar-sa" shows the following. Is America/New_York and EST not translated
on purpose?
using format: full : الأحد، 26 يناير، 2014 America/New_York 10:37:42 ص
using format: long : 26 يناير، 2014 EST 10:37:42 ص
using format: medium : 26/01/2014 10:37:42 ص
using format: short : 26/1/2014 10:37 ص
I never got around to doing the time zone localization work. At this
point, DateTime::Locale is _years_ out of date with regards to CLDR. The
approach I was using to parse CLDR and generate locales was not very
robust, so when the CLDR files changed it was a huge amount of work to
release a new DateTime::Locale.
All this is to say that we could really use an updated DateTime::Locale ;)
There are a few ways to do this:
1. Essentially what I'm doing now - which can be good enough, but is
hard to get 100% correct because of things like fallback locales, locale
"inheritance", etc.
2. Implement an ICU library in Perl that handles the full lookup reslution
logic required by CLDR. Said logic was not actually documented anywhere
last I looked, of course. So that means poking around in the Java and/or C
libraries to figure out what it should do.
3. Implement Perl bindings to libicu. I like this idea except I wonder if
this makes Windows support much harder. On the plus side, it'd almost
certainly be faster than #2 and much more correct than #1.
-dave
/*============================================================
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
============================================================*/
