cf datetime numeric units
i goofed again. when we tested the reworked timezone CFC, the test harness randomly tested just timezones but not dates. and by some bizzaro world circumstance, all the timezones it tested didn't use daylight savings time (DST). so the timezone offsets it reported passed 100%. when i was cleaning up the tests today i noticed that and ran the test against a list of timezones that use DST and dates in/out of DST. oops. all the offsets it returned were all the same as the raw offset (sans DST), even when the dates were in the DST period for that timezone. oh my.trying to fix that blunder led me into the bowels of cf where i had some trouble getting my head around the exact numeric units that cf uses for datetime objects. i was doing a javacast("long",arguments.thisDate) thinking i'd get milliseconds since java epoch to pass into java.util.TimeZone's getOffset method, ie assuming a cf datetime was a java.util.Date. but that snippet actually returns 38399 for today (16-feb-2005). which certainly doesn't look like the number of milliseconds since 1-jan-1970. recalling i blogged something about binary time scales, i whipped out a calculator to see when cf's "epoch" actually started started. 38399 turns out to be the number of days since 31-dec-1899. that makes the cf datetime object type (which is actually a coldfusion.runtime.OleDateTime) more like "Excel_Time" or "DB2_Time" which measure dates in days since their epoch started (31-dec-1899).
well the timezone CFC's fixed up now. and i learned a bit more about cf (and not to assume too much about how cf works).
posted by Paul Hastings @ 2:19 AM
2 Comments:
I noticed all the timezones listed in the dropdown. If a user were asked to pick a timezone it seems all of those listed would not apply. Question is, are there a list of display friendly timezones to pick from, maybe divided into regions (US, Europe, etc.)? It may be just a matter of sorting what is included. But any insight or guide to using the CFC would be helpful.
you could always just use the GMT offset but we've found that users need some id local to them. it's difficult to limit user's tz to a single region as they cross countries and even continents and of course many countries contain more than one tz. toss in historical tz and you have teh current olsen data.
how you manage this depends on how you need to serve tz. maybe you can explain what you're doing?
in any case, the CLDR project is working on tz data. need to wait & see who updates their lib based on it.
Post a Comment
<< Home