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:
sun.util.calendar.ZoneInfo[id="Mexico/BajaNorte",offset=-28800000,
dstSavings=3600000,useDaylight=true,transitions=149,
lastRule=java.util.SimpleTimeZone[id=Mexico/BajaNorte,
offset=-28800000,dstSavings=3600000,useDaylight=true,
startYear=0,startMode=3,startMonth=3,startDay=1,
startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,
endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,
endTimeMode=0]]
dstSavings=3600000,useDaylight=true,transitions=149,
lastRule=java.util.SimpleTimeZone[id=Mexico/BajaNorte,
offset=-28800000,dstSavings=3600000,useDaylight=true,
startYear=0,startMode=3,startMonth=3,startDay=1,
startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=2,
endMonth=9,endDay=-1,endDayOfWeek=1,endTime=7200000,
endTimeMode=0]]
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.
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.
thanks.
posted by Paul Hastings @ 2:48 AM
4 Comments:
any idea how the rules are organised?
eg: in the 4 eastern states of Australia every summer: one goes to DST earlier than the others (Tasmania) and one doesn't do DST at all (Queensland).
And if Queensland *did* do DST how do the rules get "reset"?
facinating stuff (IMHO)
cheers
the "rules" are organized by politicians, so pretty much anything goes (and has gone if you look thru the historical data). so it's not like some specific geographic region has a "natural" timezone, it has what the politicians say it has. so you end up w/some places in the US, etc. that don't use DST or have different start/end rules. and you get other interesting things like here in thailand a couple of years ago the prime minister wanted to put the kingdom into the same timezone as hong kong.
grab the raw Olsen data and have a look thru that, loads of laughs.
Q: And if Queensland *did* do DST how do the rules get "reset"?
A: it has what the politicians say it has
so that's why this is such a big deal?
"The US Congress is considering a bill to change the dates on which clocks change"
http://www.itworld.com/Tech/2987/050726daylight/
having embeded rules that are privvy to the whims of polititions? a worry...
assumming you're running java or something based on java like coldfusion, its not such a big deal (well as long as sun releases a new JVM before the new DST rule kicks in). the old rule will just become another bit of timezone history. if on the other hand you want off and created your own timezone and rules, you're going to have to scramble by golly ;-)
Post a Comment
<< Home