Re: Windows Locales
On Aug 27, 2012, at 4:11 PM, Sean M. Burke wrote: > Bernie, are you interested? (if so, what's your PAUSE ID?) > David (Wheeler), are you interested? (if so, what's your PAUSE ID?) No, I have no access to Windows at all. Thanks. David
Re: Windows Locales
On 08/27/2012 04:38 PM, David E. Wheeler wrote: Yeah. It could probably use an update. I doubt anyone is maintaining it. Is that right, Sean? Does Win32::Locale need care and feeding? Basically: yes, and... Grepping my mailbox, I see three messages in November 2006[!!!] where: * Bernie Davidson, rbdavi...@cpan.org, opens a ticket with a suggested patch to Win32::Locale. * I email him and say helo thar, good patch, and would he mind taking it over. * He says sure. ...and then I dropped the ball: I forgot to actually do it. (Namely, to log into PAUSE and do the transfer.) It's obnoxious of me to have waited *six years*, but: Bernie, are you interested? (if so, what's your PAUSE ID?) David (Wheeler), are you interested? (if so, what's your PAUSE ID?) I don't know whose affairs happen to involve Microsoft + localization these days.
Re: Windows Locales
On Aug 27, 2012, at 3:33 PM, Dave Rolsky wrote: > Heh, go figure. I think I wrote that code, but forgot about it. It strips off > any trailing character set in the locale code. You were way ahead of yourself, yo. :-) >> I found Win32::Locale, which seems to do what I need it to. > > Ah, cool. Looking at it I suspect it's probably out of date and missing some > codes that might be used in Windows since 2004, but it's better than nothing. > > I should add a mention of this to the DateTime::Locale docs. Yeah. It could probably use an update. I doubt anyone is maintaining it. Is that right, Sean? Does Win32::Locale need care and feeding? Best, David
Re: Windows Locales
On Mon, 27 Aug 2012, David E. Wheeler wrote: That locale will not make DateTime::Locale happy either. Seems okay with it: perl -MDateTime -MPOSIX -E 'my $dt = DateTime->now; $dt->set(locale => POSIX::setlocale( POSIX::LC_TIME() ) ); say $dt->locale' DateTime::Locale::en_US=HASH(0x7fc90a297dd8) Heh, go figure. I think I wrote that code, but forgot about it. It strips off any trailing character set in the locale code. With Windows, someone might want to maintain a master translation list of Windows names to CLDR names, much like we currently translate timezone names. I found Win32::Locale, which seems to do what I need it to. Ah, cool. Looking at it I suspect it's probably out of date and missing some codes that might be used in Windows since 2004, but it's better than nothing. I should add a mention of this to the DateTime::Locale docs. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Windows Locales
On Aug 27, 2012, at 2:29 PM, Dave Rolsky wrote: > I'm not sure why you think this would work on Linux either. On my system > here's what I get: > > perl -MPOSIX -E 'say POSIX::setlocale(POSIX::LC_TIME())' > en_US.UTF-8 Yeah, me too. > That locale will not make DateTime::Locale happy either. Seems okay with it: > perl -MDateTime -MPOSIX -E 'my $dt = DateTime->now; $dt->set(locale => > POSIX::setlocale( POSIX::LC_TIME() ) ); say $dt->locale' DateTime::Locale::en_US=HASH(0x7fc90a297dd8) > Of course, this one's relatively easy to make into something DateTime can > handle, whereas the Windows one is _way_ off. Either way, I think you may > need to rethink how you translate the user's locale for DateTime. > > I'm not really sure what the best way to do it is besides presenting users > with an explicit choice. > > With Windows, someone might want to maintain a master translation list of > Windows names to CLDR names, much like we currently translate timezone names. I found Win32::Locale, which seems to do what I need it to. Best, David
Re: Windows Locales
On Mon, 27 Aug 2012, David E. Wheeler wrote: The code in question that sets the locale is: $dt->set( locale => POSIX::setlocale( POSIX::LC_TIME() ) ); I'm not sure why you think this would work on Linux either. On my system here's what I get: perl -MPOSIX -E 'say POSIX::setlocale(POSIX::LC_TIME())' en_US.UTF-8 That locale will not make DateTime::Locale happy either. Of course, this one's relatively easy to make into something DateTime can handle, whereas the Windows one is _way_ off. Either way, I think you may need to rethink how you translate the user's locale for DateTime. I'm not really sure what the best way to do it is besides presenting users with an explicit choice. With Windows, someone might want to maintain a master translation list of Windows names to CLDR names, much like we currently translate timezone names. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Windows Locales
DateTimers, I got a curious test failure on Windows: http://ppm4.activestate.com/MSWin32-x86/5.14/1400/D/DW/DWHEELER/App-Sqitch-0.911.d/log-20120824T022242.txt The error was: Invalid locale name or id: English_United States.1252 The code in question that sets the locale is: $dt->set( locale => POSIX::setlocale( POSIX::LC_TIME() ) ); Where $dt is of course a DateTime object. I suspect that this locale is pretty standard on Windows, so I’m wondering how one should map Windows locales to DateTime::Locale locales? Thanks, David
datetime@perl.org
Chipping in very late on this discussion: Ted Byers on Sun, 19 Aug 2012 01:58:23 -0400 wrote: > But there remains the question of possibly incompatible timezone names as > the author of the location packeg, that gives timezone as a function of > latitude and longitude wrote in his documentation that he used posix > timezones and that some of these might be usable in the datetime timezone > packages. He implied, therefore, that some may not be. Remember the city of Urumqi in China. The Chinese people generally use the official China time zone (Asia/Shanghai) but the local Uyghur population uses a local time (Asia/Urumqi). Thus, in that city, you need to know which of the two time zones the user wishes to use — there are two possible answers, depending in part on the ethnicity of the user, and perhaps on their need to coordinate their activities with other people in the region. The latter consideration might work either way: an Uyghur might need to work with Chinese and choose Asia/Shanghai time, while a Chinese might need to work with Uyghurs and choose Asia/Urumqi time. You can find copious recent discussion about Asia/Shanghai vs Asia/Beijing during August 2012 on the t...@iana.org mailing list. You can find copious but much older discussion of Urumqi in the archives of the same mailing list (1988, 2008, 2009). You can also find some information about Urumqi in the 'asia' file delivered with the Olson database - which is where I collected the dates from. -- Jonathan Leffler (jleff...@us.ibm.com) STSM, Informix Database Engineering, IBM Information Management 4400 N First St, San Jose, CA 95134-1257 Tel: +1 408-956-2436 Tieline: 475-2436 "I don't suffer from insanity; I enjoy every minute of it!"