May 21, 2007

party like it's 1999

there was a recent aticle in Time that once again reminds me that the world is a big, complex place. while at one time Ethiopia was probably best known for famine & despair and LiveAid (though i prefer to recall their great long distance runners & links to bob marley), come september 11 (yes, 9/11) they'll literally be partying like it's 1999 because in the Ethiopic calendar (also known as the Ge'ez calendar) it is 1999. september 11 marks the end of the 20th century according to their calendar. the Ethiopic calendar, which is kind of based on the julian calendar, has twelve months of 30 days each plus a "13th" month consisting of five or six epagomenal days (fancy way of saying inserting a leap day, etc to make a calendar follow the seasons or moon phases). and since i know you're dying to know, today, 21-May-2007 (gregorian calendar) is 1999 Genbot 13 in the Ethiopic calendar (of course icu4j has an Ethiopic calendar component).

and yes, even though it helps "date" me, i am still a fan of Prince's 1999.

May 19, 2007

God helps those who help themselves

since it looks like they'll be playing ice hockey in hell before ColdFusion makes use of the very cool icu4j library, i figure we better start helping core java get it's locale resource act together. so lets start somewhere near my neighborhood, australia & new zealand.

core java's locale data for en_Au (Australia) and en_NZ (New Zealand) time formats is a bit off. it uses a format of H:mm:ss where the "H" stands for 24 hour clock, ie 5:00 PM would be formatted as 17:00. the CLDR (common locale data repository) however states that the time format for en_Au & en_NZ locales is h:mm:ss a (well actually it's proposed to include the timezone, "h:mm:ss a z" see the en_AU time format entry here). while most users in those locales are smart enough to get that 17:00 is 5:00 PM when your ColdFusion app outputs time values, it would play havoc when ColdFusion tries to parse what those same folks would normally input for a time value.

so hey en_AU and en_NZ locale people, time to start helping yourselves. Sun has accepted this as a new bug, go vote for it (you have to be a member of the Sun Developer Network to vote but these days, who isn't).

May 02, 2007

icu4j 3.6.1 maintenance release

if you're using icu4j 3.6 and supporting chinese locales you should grab this upgrade. specifically if you support zh_CN, zh_TW,zh_HK,zh_MO, or zh_SG you'll probably want this upgrade as the actual locale data is picked up from the ICU locale "zh" data bundle which does not contain any regional specific data such as currency. if i understand correctly, the locale data was keyed off scripts, for instance zh_Hans_CN or zh_Hant_TW.

if you're still on older versions of icu4j, you should be ok as this is a new bug introduced in 3.6.

Labels: