July 29, 2005

ESRI webservices

ESRI, one of the really BIG guns of the GIS industry, has stealthily released a public, non-commercial version of their extremely cool ArcWeb Service. as far as i can tell there aren't any limitations to its use beyond that it be non-commercial and they promise that it will be permanently free of advertising. we've used their SOAP APIs to talk to ArcWeb from coldfusion--it was a breeze. you can see more info here

and while we're a dyed-in-the-wool ESRI shop, this is pretty cool.

oh boy, timezone DST info

info concerning DST (daylight saving time) is one of the more requested additions to my timezone CFC. many folks have wanted to know when a particular timezone's DST starts and ends, what are it's rules, etc. i've resisted adding it as i thought the only "good" way to get at this data was via the Olsen timezone data which is kind of soggy and hard to light. a couple of days ago somebody in the forums asked about this again while i was twiddling my thumbs waiting on some tests (inserting/returning monster thumping BLOBs into sql server via cf7 w/out croaking the JVM). so i poked and prodded the java.util.TimeZone and java.util.SimpleTimeZone classes until something fell out: parse what a toString() returns on the timezone object. pretty simple, except the DST start/end logic wasn't what i'd call simple and there were several bits that weren't very well documented. for instance, here's what you get from dump the Mexico/BajaNorte timezone:


the interesting bits are the "lastRule". you can see the startDay, startMonth (remembering that java months start at 0), etc. the trouble comes in deciphering the logic for the DST start/end date parts. endDay=-1?? what the heck? if you read the javadocs API for these classes, the logic is spelt out in the API but setting up cf's logic to handle this was getting messy. that's when i noticed startMode and endMode. these values seemed like a way to short circuit that messy logic, unfortunately, these aren't really documented in the APIs. to make a long story shorter, some googling and peeking inside source code i came up with these:
  • DOM_MODE (1): Daylight savings time start/ends on the exact day of the month specified by day of month. For example, the fifth day of the month.
  • DOW_IN_MONTH_MODE (2): Daylight savings time start/ends on the day of the week specified by dayofweek that occurs in the month as specified by day of month. For example, the last Sunday of the month.
  • DOW_GE_DOM_MODE (3): The absolute value of dayofweek gives the day of the week occurring on or after the day of the month specified by day of month for which daylight savings time start/ends. For example, the first Sunday on or after the fifteenth of the month.
  • DOW_LE_DOM_MODE (4): The absolute value of dayofweek gives the day of the week occurring on or before the day of the month specified by day of month for which daylight savings time start/ends. For example, the first Sunday on or before the fifteenth of the month.
you'll find an experimental version of the timezoneCFC here. for starters i'm not 100% sure about the DST start/end logic. next the returned DST start/end times aren't (yet) compensating for the start/end time modes (standard, wall, UTC). and of course it's experimental.

in any case, i'd appreciate folks testing this and if possible maybe having a look at the DST start/end logic and letting me know of any problems.


July 22, 2005

are you fit enough?

if you're looking to get your ColdFusion MX 7.0 Certification, there's no better way to get "fit" for the actual exam than CentraSoft's CFMX Exam Buster 7.0. a boatload of questions (875 questions w/answers too ;-) covering pretty much all aspects of the actual exam, sort of like a workout w/mike tyson in his hey day except no ear-biting.

and in case you're wondering, brian simmons, who built the exam buster, is a genuine good guy. besides "exam buster" sounds like a pretty good name for comic super hero ;-)

July 02, 2005

get it while it's hot: icu4j 3.4 beta

IBM just announced the beta release of icu4j 3.4. some of the nifty new stuff in this release includes:
  • updated to Unicode 4.1
  • collation engine updated to UCA 4.1
  • fully conformant with CLDR 1.3
  • charset detection framework (which looks very useful)
  • message formatting apostophe solution
  • additional usability APIs
  • new currency listing API
  • more API for accessing CLDR data
  • Coptic and Ethiopic calendars (that makes 8 icu4j calendars and Dr. Ghasem Kiani's persian calendar for a total of 9, count 'em 9, calendars)
  • more efficient data loading
you can download the beta release here. report any bugs by july 17th.

and in case you were wondering, today (2-jul-2005) is October 25, 1721 in the Coptic calendar and October 25, 7497 (Amete Alem Era) in the Ethiopic calendar system.