Re: localized date formats

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)
============================================================*/