[development] Re-Thinking Events in Drupal (and time zones too)

Gerhard Killesreiter gerhard at killesreiter.de
Mon Mar 6 12:21:55 UTC 2006


Rob Thorne wrote:

> One of the best defenses of using Unix timestamps has to do with 
> handling daylight savings time/ summer time.  Correctly handling dates 
> in time zones that have transitions during the year is very hard to do 
> right unless you use Unix timestamps.


It is even hard using unix timestamps. Look at the bugs logged for event 
module, there is apparently still some inconsistency lurking in the code 
(or maybe people don't read the instructions).


>
> This is also why I'm not sure using database functions is the right 
> approach;  we'll just be trading one set of problems for another.  But 
> I think there's a way out of this.  I've spent some time over the last 
> day or two looking at the Arthur Olsen library, and have a suggestion 
> of how to solve the DST/ST problem in a general way.


Doing so will be quite hard. i just want to remind people of my pending 
patch here:

http://drupal.org/node/11077

Anyway, I don't see why implementing DST would be harder with proper 
date formats than using timestamps. Adding or substracting one hour 
should be easy enough if you know which DST applies.

>  
> I wrote a little perl script today that generates the needed SQL for 
> Olson's current 2006 figures.  That's the only part that would be new 
> to most of you.  I haven't written the code yet to do the calc, but 
> once most of you look at the data, it will be pretty obvious how to do 
> it.
>
> I'll a bit more info about how to do this later.  But given how many 
> countries were represented at our meeting in Vancouver, I think it's 
> worth getting this right finally.


My rather simple patch covers a largish part of the earth's landmass. 

Cheers,
    Gerhard

P.S.: Can you please educate your MUA to not cite the whole thread? Thanks.



More information about the development mailing list