[development] Re-Thinking Events in Drupal (and time zones too)
rob at torenware.com
Mon Mar 6 18:19:45 UTC 2006
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.
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
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
as they know how to set the time on their own computer).
More information about the development