October 24, 2003
October 23, 2003
timeZone CFc bug fixedJean-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 .
October 16, 2003
sunrise, sunsetbesides 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.
October 11, 2003
joel on unicodejoel 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".
October 10, 2003
w3c: draft i18n authoring techniques doc releasedw3c 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.
astronomicalCalendar betacompared 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 ;-)
October 09, 2003
cutting loose: chineseCalendar CFCok, 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.
October 07, 2003
that was easy: japaneseCalendar CFCas 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)