Jamie Zawinski wrote:
> And please remember that "every year" is not, and is never going to be
> true. Every now and then, random local and national governments in
> various parts of the world decide to change the dates on which daylight
> savings time begins/ends, or whether it is honored at all. And
> sometimes the timezone of a city/country changes (this occasionally
> happens with places near the borders.)
>
> The Olson database contains all of the historical record for this.
> So it can answer your questions about when DST flipped in a particular
> year in the past, and can make the assumption that future years will
> be the same. But they might not.
Yes, I have taken that into account.
> I really think you're making a mistake if you don't use the Olson code
> directly for this. Rolling your own time-hacking code is not just a
> recipe for disaster -- it *is* disaster. No matter how little fun it
> sounds like to bend your APIs and requirements to use the Olson code,
> I guarentee you that the bugs (and freefloating hate) you'll get as a
> result of *not* using the Olson code will be even worse. It's a
> snakepit. Stay out.
I don't think it is actually that bad.
The way I've done it is:
o For each timezone, keep a sorted array of times that local time
changes (i.e. clocks go back/forward).
o To convert times between timezones you convert first to UTC, then
convert from UTC to the other timezone.
o To calculate the UTC offsets you do a binary search to find a
time change in the sorted array above which is fairly close.
Then you step backwards or forwards through the array until you
find the timezone change which applies. (You have to be a bit
careful around time changes because of the time overlaps etc.)
The only difficult step is the last one, and even that isn't too bad.
Unless you can think of some problem I've missed.
Damon
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution-hackers
