FAQ
I would like to simplify our localization of dates and, if possible, just
use this format for timestamps:

$dt->strftime( '%x %X' );


First question, is there any difference between the above and this?

            join ' ' , $dt->format_cldr( $locale->date_format_default,
$locale->time_format_default )

Second, do timezones get localized? For example, here's the default
formats for "ko":

using format: full : 2014년 1월 16일 목요일 오후 05시 10분 28초 America/New_York
using format: long : 2014년 1월 16일 오후 05시 10분 28초 EST
using format: medium : 2014. 1. 16. 오후 5:10:28
using format: short : 14. 1. 16. 오후 5:10

Won't be using the "full" format, but showing a timezone is needed. Can
(or does?) EST get localized?

Thanks,







--
Bill Moseley
moseley@hank.org

Search Discussions

  • Bill Moseley at Jan 26, 2014 at 3:47 pm
    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-parsingthere'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 ص



    On Thu, Jan 16, 2014 at 2:29 PM, Bill Moseley wrote:

    I would like to simplify our localization of dates and, if possible, just
    use this format for timestamps:

    $dt->strftime( '%x %X' );


    First question, is there any difference between the above and this?

    join ' ' , $dt->format_cldr( $locale->date_format_default,
    $locale->time_format_default )

    Second, do timezones get localized? For example, here's the default
    formats for "ko":

    using format: full : 2014년 1월 16일 목요일 오후 05시 10분 28초 America/New_York
    using format: long : 2014년 1월 16일 오후 05시 10분 28초 EST
    using format: medium : 2014. 1. 16. 오후 5:10:28
    using format: short : 14. 1. 16. 오후 5:10

    Won't be using the "full" format, but showing a timezone is needed. Can
    (or does?) EST get localized?

    Thanks,







    --
    Bill Moseley
    moseley@hank.org


    --
    Bill Moseley
    moseley@hank.org
  • Dave Rolsky at Jan 27, 2014 at 3:34 am

    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)
    ============================================================*/
  • Bill Moseley at Jan 27, 2014 at 3:55 am
    On Sun, Jan 26, 2014 at 7:34 PM, Dave Rolsky wrote:

    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.
    Yes, that does sound like the way to go. I'll ask at work if anyone has
    experience with libicu, but it wouldn't be anyone also with XS experience.

    Any suggestions on what to do in the near term working with current
    DateTime? Punt with "26 يناير، 2014 EST 10:37:42 ص"?


    Thanks,

    --
    Bill Moseley
    moseley@hank.org

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdatetime @
categoriesperl
postedJan 16, '14 at 10:29p
activeJan 27, '14 at 3:55a
posts4
users2
websitemetacpan.org...

2 users in discussion

Bill Moseley: 3 posts Dave Rolsky: 1 post

People

Translate

site design / logo © 2019 Grokbase