The event module is a wonderful and useful application, but there are a number of well-known problems that revolve around problems timezone and gmdate conversions -- i.e. calendars that show the current day that are one day off late in the day. If you track through the code to see what is happening to a date you can see that there are a lot of places where a gmt conversion gets duplicated, for instance, when a timestamp that was converted to gmt gets passed to another function that creates months and years by using gmdate on that timestamp that already had a gm conversion. The last time I checked there were 130 places where the event module has a gmdate or gmmkdate function. No wonder things are getting confused!

Here's my thinking (and this would involve major surgery of the event module). Instead of passing around a timestamp and calculating years, months, and days over and over in 130 places in the code, what about creating a date object and passing that object by reference. The object would look something like the following:

$date->
gmt->timestamp
gmt->year
gmt->month
gmt->day
gmt->hour
gmt->minute
gmt->second
local->timestamp
local->year
local->month
local->day
local->hour
local->minute
local->second
local->timezone

Then, instead of doing gmdate("Y", $timestamp) to create a year, functions would just grab $date->gmt->year. If they need a local year, they would instead grab $date->local->year. That would eliminate the chance that they are duplicating a previous gm conversion. Even better, all the conversion from gmt to local would happen in once place, in the date class, so if there are errors in the conversion logic they can be fixed in that that one place.

The process I envision would be to create the event date class, move all the functions that involve conversion logic and local timezone identification into that class, go through the code and set it up so that each function that needs to manipulate a date is passed the date object by reference, then eliminate all the gmmktime and gmdate calls and replace them with things like $date->gmt->timestamp.

I would be willing to work on this if there is interest.

Comments

Patrick Nelson’s picture

Patrick Nelson commented

Karen,

I'm definitely interested - problems with dates are quite significant on some of our Drupal sites.

I notice you doing a lot of stuff with Event recently. I know this is off topic but do you have any thoughts about integration with Google Calendar (as mentioned in this post)?

Regards

Patrick

karens’s picture

karens commented

Maybe no one else but the two of us is interested in this approach?? If not, I won't bother with the considerable work involved in doing this. The more I look at the event module the more I think this approach or something similar is the only thing that will do more than put a band aid on the date handling problems. It looks like the problems are most pronounced if you are in a time zone far from gmt, are trying to use something other than the site timezone, or have a server that is set to a timezone different than the site timezone, so not everyone is similarly affected, and some people may not even be seeing any problems. All the other parts of event seem to be working fairly well, or would be if the date handling was fixed.

As for Google Calendar, that could be interesting, but I really haven't tried to do anything with ical at all, so am not going to be much help. Might think about working on this later, if no one else steps up.

TKS’s picture

TKS commented

I would love to see the event module streamlined like this -- in addition to fixing some of the time/date oddities, your proposal would also make it easier to create custom event views, wouldn't it? (Simply by making it absolutely clear where to grab the data/object you need.)

dan90’s picture

dan90 commented

+1 from me. fro the even module at least. Shoudl we be thinking, though about impementing a date object as a thing which could be accessible for other modules? It sounds like very generally useful functionality - and events aren't the ony things needing timezone correction...

karens’s picture

karens commented

Actually I think that the ultimate solution might be the cck date module. I think the plan is that it will become a comprehensive solution for dates in other modules.

kloomis’s picture

kloomis commented

Several of my sites use events extensively. This proposed change would be terrific, and very well consistant with good coding practices. Please go ahead.

chromeyellow’s picture

chromeyellow commented

I've been grappling with event.times too, and agree that this may be the solution. (I worked out a temporary and surprisingly simple fix for 4.6 at node/56189, which kloomis has kindly tested. Briefly, event.module does indeed create a single $stamp variable, which it uses most of the time. The problem was, as you've noted, that it gmt's the stored timestamp when it creates the $stamp, and then just keeps on gmt-ing it, over and over.)

But one thought - I'm wondering if events need a pure timestamp at all? Maybe this can of worms was opened and shut for a reason ages ago - but I've begun to think an event should be stored not as a machine friendly timestamp value, but as a simple, human readable YYYY/DD/MM or whatever, with an optional HH:MM (with the bonus that the HH:MM value could be set to a nice plausible default like 9:00 am, rather than always defaulting to the current hour.) Mysql, and I assume postgre, has a few useful native date formats to consider.

(Not asking you, KarenS, to make this decision - but maybe interested parties have arguments for or against this thought?)

scroogie’s picture

scroogie commented

I dont know if the whole abstraction is needed, I just wanted to point out something:
There is a mature PEAR Class (first release 2002) which you could use as a first archetype. Quote from the project page:

Generic classes for representation and manipulation of
dates, times and time zones without the need of timestamps,
which is a huge limitation for php programs. Includes time zone data,
time zone conversions and many date/time conversions.
It does not rely on 32-bit system date stamps, so
you can display calendars and compare dates that date
pre 1970 and post 2038. This package also provides a class
to convert date strings between Gregorian and Human calendar formats.

killes@www.drop.org’s picture

killes@www.drop.org commented

No PEAR stuff will be committed to event.module.

The approach to KarenS looks ok to me, I'd like to discuss it with crunchywelch, though.

Of course we can't have classes, but will encapsulate everything in a nice function. ;)

scroogie’s picture

scroogie commented

No, it wasnt meant for being included. You would have to include Pear.php etc., too. It was meant as an archetype/example/model.

bomarmonk’s picture

bomarmonk commented

Any progress on this patch? I am getting the gmmktime errors often in 4.7 with XAMPP (my test site).

karens’s picture

karens commented

I'm not working on this right now, I don't know if anyone else is. It's basically a discussion at this point rather than a patch.

tanepiper’s picture

tanepiper commented

Anything further on this? I am new to Drupal, and I am currently building a site for a band, it would be very handy to show my new 'Gigs' content type on the event calendar. Currently the only way I would be able to do it is to list each event in a page, and manually update it (which is similar how I am currently doing it with their HTML site) :(

pwolanin’s picture

pwolanin commented

The even module works, there are jsut some minor bugs.

As far as this approach, could this be part of the 5.x update? I don't see much progress yet except for: http://drupal.org/node/73274

simon georges’s picture

simon georges commented
Status: Active » Closed (won't fix)

This version of Event is not supported anymore. The issue is closed for this reason.

Please upgrade to a supported version and feel free to reopen the issue on the new version if applicable.