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

[Rob Thorne]

Gerhard Killesreiter wrote:
>
> 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).
>
There are many ways to solve any problem incorrectly :-)  And if a 
solution gets used incorrectly very often:  arguably this is a UI problem.
>
>>
>> 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:
>
Easier than you think.  Ultimately, the best proof of my point is to 
simply implement this.  I've already solved the TZif ==> SQL problem, 
and have a complete SQL version of the 2006 tables.  This was the piece 
where I had questions of feasibility.  The rest is wrapping the GMT time 
functions.  It really isn't any more complex than what we're doing now.
> http://drupal.org/node/11077
>
It's not a bad solution, and it's certainly better than what we were 
doing before.  As you point out, using UTC/GMT internally is the right 
approach.  But Gordon's comments are spot on:  it's too simple for many 
purposes, and people don't care if it does *most* of the world right if 
it doesn't do their particular piece of it right.

Olson's data and much of his C routines, since it's the basis of 
essentially all of the code in most modern operating systems, does it 
better than anyone else.
> 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.
>
Let's temporarily ignore the fact that there are quite a number of DST 
rules available, not all of which are in the patch.

The reason to use timestamps is so you can do binary search on a lookup 
table.  This is especially true because you can easily get the 
"transition time" series for any time zone (i.e., geographic area with a 
standard UTC offset and transition times).

Another cool reason:  because if a user tell you their country, a very 
simple JavaScript test on their browser will give you their exact time 
zone info (check the offset at 1 January, check the offset at 1 July).  
So there is a very simple AJAX solution that will make almost all of the 
time zone setting UI unneeded for any user with JavaScript on (as long 
as they know how to set the time on their own computer).

Rob