October 24, 2003

g11n cf article on macromedia

there's an article about making g11n cf applications on macromedia's developer center. It's kind of light on CFC usage as i'm still trying to get my head around how to best use them in g11n apps. i'm still spinning my wheels over using a locale object as the core for this (per locale): - formatting functions - calendars - addressing - language metrics, BIDI, etc. - timezones - what not any ideas?

posted by Paul Hastings @ 1:49 AM 0 comments

October 23, 2003

timeZone CFc bug fixed

Jean-Baptiste Clot found a bug in the timeZoneCFC concerning the inDST function (tells you whether a date is in daylight savings time. it was one of those java bah humbugs. the CFC makes use of a gregorian calendar object (the original java one not ICU4J) where MONTHs are zero-based, that is january is 0. btw the other fields in that object aren't zero-based and that's my excuse for this one. i was constructing the calendar object using year, month, day, hour, minute pulled from the argument date by equivalent cf function where months aren't zero-based. so the dates that were actually being tested were one month in the future. its fixed and you can find the testbed here. the file in the devnet gallery will be available soon, in the meantime you can find the fixed CFC here .

posted by Paul Hastings @ 12:41 PM 0 comments

October 16, 2003

sunrise, sunset

besides being a song in fiddler on the roof, sunrise and sunset is an important part of some calendar calculations. i have been using the ICU4J astronomical calendar but once i got around to double checking the sunrise/sunset times it produced for bangkok i found it be off by almost 3 minutes, not a big deal over day for a calendar, but is kind of meaningful for other stuff like twilight calculations (and i just like to get stuff as correct as i can). so i hunted high and low and found a pretty accurate java package. btw, the majority of stuff i looked at was wrong, some of it laughably wrong (not to say my port to CF is perfect). in any case its posted to the devnet exchange where it be available eventually. the test bed is here. i guess this would be all sort of ho-hum so i spiced up the CFC a bit by including over 2,500 locations world wide. the access database accompanying the CFC contains names, locality, country longitude, latitude, and raw GMT offset. the actual timezone info (as used in java) is a bit harder to come by. the next version of this CFC should hopefully have that info plus more detailed data in the US and europe.

posted by Paul Hastings @ 3:48 AM 0 comments

October 11, 2003

joel on unicode

joel on software has quite an extensive article on unicode. the article does a nice review of UTF-8, encoding issues and debunks some nonsense about unicode. its also got a bunch of good resource links peppered throughout the article. all in all, a very good read. he points out one interesting issue about PHP, which i never knew because i don't use it, it doesn't natively support unicode. its got a couple of functions to encode/decode UTF-8 but all i can say about that is "bah, humbug".

posted by Paul Hastings @ 1:36 PM 0 comments

October 10, 2003

w3c: draft i18n authoring techniques doc released

w3c has released a draft ("very draft" might better describe it) doc entitled "Authoring Techniques for XHTML & HTML Internationalization 1.0". the article quite rightly emphasizes i18n from the git go rather than as an after thought and covers a lot of practical stuff. one statement i stood and cheered for was "Choose UTF-8 or another Unicode encoding for all content". i just wish more cf folks would understand that, it would make their lives a lot simpler. the doc, while only about half done, is also chock full of useful resources. makes good reading in any case. you can find it here.

posted by Paul Hastings @ 12:31 PM 0 comments

astronomicalCalendar beta

compared with the other five calendars, this one's turning into a real barn burner. astronomicalCalendarCFC, determines the positions of the sun and moon, the time of sunrise and sunset, moonrise and moonset, moon phases (full, new, etc.), vernal equinox, summer solstice, etc. for the most part, the CFC seems to work Ok but there are a few sticky issues or at least things i don't quite get. the getSunrise/getSunset functions are supposed to return the GMT time of sunrise/sunset on the local date to which this calendar is currently set (i construct each astronomicalCalendar object with a location, lat-long and then set a date). for Bangkok, where the testbed server is, the returned sunrise, etc. times seem reasonable enough. however for sites in north america, like Philly, Scranton or Saskatoon the sunrise/sunset times appear reversed. i can't tell (yet) whether these are the GMT times for their local sunrise/sunset or the local times for the testbed server (GMT+7). or something else entirely. this ICU4J calendar class is sort of experimental, so the docs, etc. aren't the clearest. need more testing before this thing can be shipped to the devnet gallery. the testbed is here. if you want to play around w/the CFC as it now stands, you can download it here. ho hum. well at least this posting hasn't mentioned the EOLAS Patent ruckus (until now ;-)

posted by Paul Hastings @ 12:30 AM 0 comments

October 09, 2003

cutting loose: chineseCalendar CFC

ok, now for the chinese calendar. like the preceding calendars, its based on ICU4J. the traditional Chinese calendar is a lunisolar calendar (the same type as the Hebrew calendar). months start with a new moon, with each month numbered according to solar events. why? to guarantee that month # 11 will always contains the winter solstice. how? leap months are inserted in certain years (i feel another non-gregorian calendar induced headache coming on). these leap months are numbered the same as the month they follow. which month is a leap month? depends entirely on the movements of the sun and moon (i.e. i can't follow the math very far) . the normal ERA field differs from other calendars as it holds the 60 year "cycle" number, right now we're in the 78th cycle which began in 1983 AD. years are counted sequentially, numbering from the 61st year of the reign of Huang Di, 2637 BC, which is designated year 1 on the Chinese calendar (yes, that's right, this calendaring system is over 4,000 years old). let's look at an example: 星期三 20x78-9-13 where 20 is the year in the current cycle, 78 is the cycle for this calendar (ERA in other calendars), 9 is the month and 13 is the day. since ICU4J's ChineseCalendar defines an additional field (for leap month) and redefines the way the ERA field (no longer AD,BC, etc.) is used, this CFC has to use a different date format class, ChineseDateFormat. this CFC adds 4 generic functions (i forgot that some calendars need special date logic): - isBefore to compare two dates to tell if one is before the other - isAfter which compares two dates to tell if one is after the other - getJulianDay returns the true Julian day for a given date - getExtendedYear returns the extended year, i.e. years since calendar start (in this case, current year + 2637) i'll retrofit these to the other non-gregorgian calendars. the date logic is probably more useful to the calendars that use calendar math different from the gregorian calendar (chinese, hebrew, islamic). and 7 functions that are specific to this calendar (though i guess some can be applied to other calendars): - isLeapMonth determines if a given date is in a leap month - getCycle returns cycle for given date - getCycleYear returns year in cycle for given date - getMonth returns month in cycle year for given date - getDay returns day in month for give date - getDayOfYear returns day of cycle year for given date - getWeek returns week of cycle year for given date the CFC's testbed is here. posted to the devnet gallery where i guess it will become available sooner or later. next the astronomical calendar. this is one is quite tricky, its also somewhat in a state of flux (the ICU4J team's working on this code) but since it forms the basis of some of the existing calendars might as well give it a shot.

posted by Paul Hastings @ 12:25 AM 0 comments

October 07, 2003

that was easy: japaneseCalendar CFC

as promised on the 5th, a japaneseCalendar CFC based on ICU4J. the Japanese calendar, sometimes called the Japanese Emperor Era calendar, is identical to the Gregorian calendar except for the year and era (which is why it was so easy to turn into a CFC). each emperor's ascension to the throne begins a new era. each new era's years are numbered starting with 1 (the year of ascension). what could be simpler? the "modern" eras:
  • Meiji: January 8, 1868 AD
  • Taisho: July 30, 1912 AD
  • Showa: December 25, 1926 AD
  • Heisei: January 7, 1989 AD (current era)
you can find the testbed here. note i've added a function to determine the day the week starts (for use in some calendaring components i'm working on). it actually depends on your locale. in Thailand & the US, a week starts on sunday. in France, Poland, etc. it starts on monday. the calendar used (as far as ICU4J is concerned) doesn't matter much. i'll update the other non-gregorian calendar CFC after i'm thru with the next two calendars: chinese and astronomical. this CFC should appear on the devnet gallery soon enough.

posted by Paul Hastings @ 7:42 PM 0 comments

October 05, 2003

an Islamic Calendar CFC

so far i've built CFCs for the Hebrew and Buddhist calendars, both based on IBM's standup ICU4J java lib. now its time for the Islamic calendar. and whether you like it or not, here comes the usual background info dump. resistance is futile, you will be globalized. the Islamic calendar (also known as "Hijri" since it starts at the time of Mohammed's emigration or "hijra" to Medinah on thursday, july 15, 622 AD ) is the civil calendar used by most of the Arab world and is the religious calendar of the Islamic faith. it is a strict lunar calendar. an Islamic year of twelve lunar months therefore does not correspond to the solar year used by the Gregorian calendar system. an Islamic year averages about 354 days, so viewed from the Gregorian calendar, each subsequent Islamic year starts about 11 days earlier. the civil Islamic calendar uses a fixed cycle of alternating 29 and 30 day months, with a leap day added to the last month of 11 out of every 30 years (oh joy, 11 days shorter and now this--i've run out of fingers and toes). that makes the calendar predictable so it is used as the civil calendar in a number of Arab countries. the Islamic religious calendar is based on the observation of the crescent moon. sounds simple enough. but that observation varies from where you at when you look (your geography), when you look (sunset varies by season you know) , moon orbit "eccentricities" (i'll take the astronomer's word for that), and even the weather (too cloudy and you obviously can't see the moon). all this makes it impossible to calculate in advance, so the start of a month in the religious calendar might differ from the civil calendar by up to three days. that makes knowing which calendar variant folks use very important. in any case, ICU4J short cuts all this, for the sake of speed, by using approximations of the astronomical calculations. the islamicCalendarCFC test bed is here. if you've looked at the other two calendar CFC you should notice i've tried to maintain function and argument conventions across these CFCs. the islamicCalendar CFC differs in that it has an optional boolean "useCivil" argument to tell the CFC which calendar variant to use. this CFC will bubble up in the devnet gallery soon enough. next up is the Japanese calendar.

posted by Paul Hastings @ 8:58 PM 0 comments

October 03, 2003

silent but deadly

ran into a nasty issue with dateDiff returning the equivalent of a java Long (32bit int). which is fine if you use dateDiff for years, months, days, etc. however if you want minutes or seconds dateparts and the date difference is large, say the difference in seconds between 1-jan-1970 and 1-feb-2038. your app will silently kill itself, the Long value the dateDiff function returns will quitely wrap to negative. i lost quite a bit of sleep tracking this down for my non-gregorian calendar CFCs (based on icu4j). you can see teh issue quite clearly here. so if you're dealing with small dateparts and large date differences, watch out for this. i have to thank andrew tyrone for first finding the bug in the hebrewCalendarCFC & steven r. loomis for working with me to track down the problem with icu4j.

posted by Paul Hastings @ 2:46 AM 0 comments