It turns out both the Event module and the Date API are trying to set site and user timezone names, and the Event module wins because it comes later in the alphabet. This completely breaks the Date API because these values are not getting set.

I need a way to store the site timezone name in a variable called date_default_timezone_name and the user timezone name in the user record as timezone_name, and I see a couple possible solutions:

1) You could set those values at the same time you are setting your own values, and I can test if your module exists and stay out of the forms if it does.

2) You could test whether the timezone names are already set and use the timezone names to do whatever you need and stay out of the forms.

I can go either way, whichever you'd rather.

CommentFileSizeAuthor
#29 event-date.diff4.04 KBliveoutloud2day
#27 event-date.diff4.02 KBliveoutloud2day
#25 event-date.diff7.31 KBliveoutloud2day
#25 event-5.x-2.x-dev-date.tar_.gz174.89 KBliveoutloud2day

Comments

killes@www.drop.org’s picture

killes@www.drop.org commented
Assigned: Unassigned » killes@www.drop.org
Priority: Critical » Normal

I need to think about this.

macgirvin’s picture

macgirvin commented

subscribe

gerhard killesreiter’s picture

gerhard killesreiter commented

Karen, where do I find the definition for date_timezone_names?

karens’s picture

karens commented

Not sure what you mean by 'definition'. If you mean where do you get the list of names, it comes from the Date API function date_timezone_names() which gets the values from the PHP 5 function timezone_identifiers_list() if PHP 5 is available, otherwise from an included file that has an array of timezone names (that file is only included for people using PHP 4).

I think you already have the timezone names in your current processing, I just need to get the selected timezone name stored in the right places. Or you can check whether the timezone name is already stored and update your zid from that.

killes@www.drop.org’s picture

killes@www.drop.org commented

I was looking for the function's definition which I for some reason failed to find. %-}

The problem with the timezone definitions from php5 is that I don't use them and thus yours and mine aren't neccessarily compatible. I also don't store the name but the ID I've assigned.

So I am guessing we'd need some kind of mapping?

karens’s picture

karens commented

Your timezone names (not the zid but the name) should map just fine to the PHP 5 timezone identifiers. So if you have a function to get the timezone name from a zid like event_get_timezone_name($zid), doing something like the following should be all we need to set the site timezone name:

if (module_exists('date_api')) {
  variable_set('date_default_timezone_name', event_get_timezone_name($zid));
}

And for the user timezone name:

if (module_exists('date_api')) {
  db_query("UPDATE {users} SET timezone_name='%s' WHERE uid=%d, array(event_get_timezone_name($zid), $uid);
}
killes@www.drop.org’s picture

killes@www.drop.org commented

I am afraid that won't work. My timezone names are made to be human readable. The PHP timezone names have for example underscores in some places. That's actually why I didn't want to use them.

Example:

Pacific/Port_Moresby

PHP seems also to have 100 more zones than I do.

karens’s picture

karens commented

The timezone names with the underscores are going to be needed anytime anyone wants to use PHP 5 date functions (which I assume we will be using to get timezone handling working right in core in Drupal 7) and they are also the timezone names needed if you want to do timezone conversions in the database, so it might be useful for the Event module to provide a way to map the zids and non-standard names to the standard timezone names to make it easier to integrate event information into Views and other non-Event modules. Then we could use that mapping function to get from one to the other.

macgirvin’s picture

macgirvin commented

@killes: I really hope you don't plan to try and maintain yet another broken daylight savings table - which incidentally is wrong for Australia. When they change the Australia rules (which they seem to do every year or two) I currently have to load in fixed tables for Linux, Windows, MySQL and PHP for about 500 computers. I just went through this in the U.S. two years ago when they changed the rules there. I probably wouldn't mind adding in yet another system patch to get it right, except the event module isn't (right). A lot of people have spent a lot of time trying to keep daylight savings tables up to date for all these disparate systems with all the geopolitical time changes going on. You're much better off joining them than going your own way. Trust me on this. Been there, done that.

killes@www.drop.org’s picture

killes@www.drop.org commented

I am actually wondering how many users use both event and date together.

@macgirvin: I'd happily use the PHP functions if the DST implementation were better . Do you think the average sysadmin would update PHP only if the DST somewhere on the globe change? It would be much easier for me to update event.module if people would file patches...

If I were to implement the event module today I'd probably also use PHP's implementation. However, this module is about seven years old and so has it's own cruft.

macgirvin’s picture

macgirvin commented

Understood... it's up to you if you want to keep up with the DST chaos, but I question the ability to commit to it long term. I tried to do this with an enterprise server product in 1999-2000 and gave up after the Sydney Olympics/Y2K madness. Things have only gotten worse since then.

I've got one site running here (Australia, I'm a yank transplant) using the Event module at a grade school and the folks using it aren't happy that event times aren't right. It was a volunteer job so I haven't bothered to invest time in fixing it or filing issues. I've pre-patched a few 5.x and 6.x sites here at the university with the DST in core proposed changes to keep them happy. They won't use Event until it works with Sydney time for an entire year's worth of activities; which may have been true last year but broke down in March 2008.

The Date module probably could've accomplished the basic time keeping in retrospect, but seemed to be a bit of baggage to carry just for the sake of getting the node times right. However, it's a very nice piece of code (have a look). That's what I recommend to others who are adverse to patching.

I've mentioned in passing elsewhere that one possible Drupal future could be for Event to be a consumer of the Date code as a base and pre-requisite going forward. Many of us are sick to death of 'date/time off by xxxx' bugs (and 'calendar showing wrong yyyyy' bugs) which have plagued Drupal/Date/Event for several years now. Date is the most correct implementation available today.

I realize it's a lot of work no matter which way it goes, but maintaining yet another DST database is likely to be even more work in the long run. I don't recall if the EU changed DST when the US did a couple years ago, but if not, they're likely to follow suit just as AU did - and that's yet another 'if $year >= xxxx && $year < yyyy' block of code to add for a sizable chunk of zones. I've looked through Event and there are a whole lot of (known to me) global DST events which aren't coded, even with just a quick read.

The underscore timezone syntax is the likely winner in the long run, since that's what many of the system timezone libraries use, even if you (meaning Event) prefers not to. It may not be restricted to Date alone, as the standard zone names could be put to use by any module and manipulated with PHP. If Event has different names, then each module wishing to do timezone calculations will have to translate the names or have yet another table to maintain, perpetuating the madness.

killes@www.drop.org’s picture

killes@www.drop.org commented

macgirvin: This is open source, you are supposed to contribute back. So please create issues and patches for whatever problem you have with event.module.

Date's sql model is still lacking and therefor is not the most correct implementation. Since I myself was sick of the tz issues I rewrote the entire event codebase last year to use real sql datetime fields and since then they are mostly gone (with exception to DST issues nobody carse enough for to even file an issue...)

macgirvin’s picture

macgirvin commented

Apologies as this has devolved a bit from the core issue, but was done so in the context of understanding why both modules can't play together. I see the reasons, but this isn't arriving at a solution. It seems that both modules use quite different conventions for storing data in the same fields and have different expectations of what data will in fact be stored there.

If they cannot both be made to work with the same data (which appears to be the case), the only possible solution is to separate them into areas where they will not collide - even though at a high level they provide mostly similar context and functionality. Please tell me if I've missed something, but I'm failing to see any other possible resolutions.

karens’s picture

karens commented

This affects not just people using the CCK Date module, it affects any module that uses the Date API. But it also affects any other module that wants to use PHP 5 date handling, including any custom code a developer might want to add, since there is now no way to collect the timezone names needed for that to work.

You're asking for the timezone name in those forms now, but you're ignoring the timezone name and storing your zid (which is useless to any other module). Since you're overriding the timezone forms to ask for timezone names but are not storing them, it's impossible for any other module to have a way to set site and user timezone names.

That means that no module or custom code that needs PHP 5 or MYSQL timezone handling can be used on any site that is using the Event module. That seems pretty restrictive.

Also, for whatever it's worth, I disagree that the date module's sql is lacking -- it always needs more work, I'm working on it now, but I've spent many many hours trying to create flexible cross-database date sql for Views and a universal Date API that can be used by any module, not just the date module, and that's a bigger project that creating sql specific to a single application. I've been trying to develop a central method of handling dates in Drupal, including a single way of collecting and storing timezone names that I hoped other modules could share.

The date module relies on CCK for its storage sql and on Views for most everything else instead of creating all its own sql and that is one of the differences between Event and Date. Another difference is that Date stores the UTC values while Event stores the local values, and that obviously changes the kind of sql needed to retrieve the results.

BTW, the PHP 5 timezone files have all the historical timezone info, going back to World War II and before, so it is extremely comprehensive, and it would be quite a project to try to replicate anything close to that in custom code. If you only work with current dates it may not matter, but that could be an issue where older dates are being used.

luusl’s picture

luusl commented

Are there any guesses when we could assume to have a compatible release or simply a patch which would fix that issue? Maybe just a silly thougth, but wouldn't it be better if the event module uses the date api to resolve such conflicts and avoid maintenance of similar code?

killes@www.drop.org’s picture

killes@www.drop.org commented

@Karen: If saving the time zone name into date_default_timezone_name will make you happy, I'll gladly do so. I'll even replace spaces by underscores which is the only difference in naming that I've come across. The only problem would be that there are some timezones missing.

Historical correctness of tz data is sure a concern for a general date API. It is not for event.module which mainly deals with current events.

karens’s picture

karens commented

@killes, that would be great. I'm not worried about missing timezones, I'm going to limit the timezones to the ones in the core patch at http://drupal.org/node/11077.

That patch also needs a way to get PHP timezone info from the Event module when we do the D7 update, so maybe there's a way to use this as an opportunity to create a function that will return the PHP timezone for the site or a user from your zid info.

killes@www.drop.org’s picture

killes@www.drop.org commented

Ok, I will try to come up with a patch by next week. I will also look at that core patch to make sure event users aren't left out in the cold.

Generally, I am not sure that relying on PHP's date database is a good thing as the only constant about hosted PHP installs is that they are out of date (pun intented...)

karens’s picture

karens commented

Well there is going to be another problem. The core timezone patch limits timezones to the ones that are officially recognized, the ones that start with continent names -- America/Chicago, Europe/Berlin, etc. There's a long list of deprecated timezone names, including ones like US/Central. You still have many of those deprecated names in your list but I'm updating the Date module to remove them, so if your code is used to select a timezone, it may be a deprecated zone that won't work in the Date module.

I've come up with a list of replacement zones for the deprecated zones so I can do an update to get the deprecated zones out of the Date database and I'd be glad to offer it to you if you'd like to get them out of the Event database, too. Then both of us will have the same, much shorter, list of official timezones that will match where D7 is headed.

franz-m’s picture

franz-m commented

> "I am actually wondering how many users use both event and date together."

I e.g. happen to do ...

The problem remains: the site gives the error-message about the timezone even to *anonymous users* (it would be less pressing if it only happened logged in).

I had re-loaded the latest versions of date and event today
date-5.x-2.0-rc.tar.gz (no change with date-5.x-2.x-dev.tar.gz)
event-5.x-2.x-dev.tar.gz

Drupal 5.7 PHP 5.2 Mysql 4.1.22

(For the moment as workaround I just patched out the error message)

GoofyX’s picture

GoofyX commented

Subscribing...

GoofyX’s picture

GoofyX commented

I'm also using both Event and Date and I experience this kind of behaviour: I create an event with a starting date of eg. June 1st, 9am. The event is displayed fine. If I go to the calendar view, the event start date is 7 hours later (5pm), which makes me think it's the problem with the timezone as described here.

I'm using Event 1.0 and Date 2.0-rc. As the client is pressing me, I would really appreciate it if someone told me that there's an at least temporary solution for this behaviour until a proper fix is found.

ambereyes’s picture

ambereyes commented

subscribe.

ambereyes’s picture

ambereyes commented

Just a quick note to say that I would prefer to use both Date and Event. The reason is that they offer different types of solutions.

Event repeat allows me to create separate nodes from a single entry which I need to create event registration for repeating sessions, i.e. a seminar offered every month on the first Tuesday.

The date repeat module allows me to select ranges of days for a single node which makes it easier to display availability info for repeating activity like mediation practice on every Monday through Wednesday at 6 am, Friday and Saturday at 7 am and Sunday at noon.

And date allows me to create content types with arbitrary date fields.

The main problem is that I cannot display all event type info on a single calendar using both implementations.

So yeah, this is a critical issue for my sites.

--
www.ambereyes.net

liveoutloud2day’s picture

liveoutloud2day commented
Status: Active » Needs review
StatusFileSize
new event-5.x-2.x-dev-date.tar_.gz174.89 KB
new event-date.diff7.31 KB

I too would like to be able to do all the nice things events allow (resource reservation, rsvp, etc) but want to use a date field on things (requiring the dateAPI). I have made a patch that makes that work for me, sharing it here. The patch to event involves checking for the version 5.2 of date, and acting accordingly. It includes an update script for event, but only changes the names of some of the timezones to have underscores instead of spaces. I wasn't able to do a full blown update of the timezones involved, because I wasn't sure by this discussion what you wanted changed. This makes it so that if someone is just using the event module and runs the update script, they still have more timezones than date has, but they match (ie America/New_York = America/New_York). If they are using the date module, the list of timezones comes from the date module, as it is a subset of the ones you have.

The patch changes the submit to check for date, and if it exists sets the date_default_timezone_name. If date does not exists, it does everything the same (except the changes to timezone names already mentioned.) It also includes a function for selecting the event_timezone info from a timezone name instead of an id, as this is what date uses.

I am including 2 files, one is the patch file, and one is the module itself. I am including the whole module, because you have not yet released a 5.2 version yet, and since the dev version can change, my patch file is likely to not apply cleanly later. The included diff file applies cleanly to the dev version downloaded today (dated 16-Jul-2008), from the modules directory with a patch -p0 <event-date.diff command.

Please consider using this patch as it changes very little and has the benefit of allowing the modules to work together.

Hope it helps!

liveoutloud2day

karens’s picture

karens commented
Status: Needs review » Needs work

@liveoutloud2day - your patch gives me an idea I didn't think of before. If you re-roll this patch to just detect whether the Date API is installed, and if so, do nothing on these forms, I'll patch the Date API to update the Event module values. Every timezone that the Date API uses is valid for Event, but not vice-versa, so we need them to select a timezone from the Date module list. From there it is a fairly simple thing for the Date module to get the right values stored for the Event module. Really no need for the Event module to figure out how to resolve the differences, the Date module can do that part.

That would make this into a very trivial patch for Event.

liveoutloud2day’s picture

liveoutloud2day commented
Priority: Normal » Critical
Status: Needs work » Needs review
StatusFileSize
new event-date.diff4.02 KB

Great idea! All that this event patch needs to do if the date module is installed, is to step around the site and user timezone form entries AND the submit part (didn't think of that). Also, needs that new function that you are keying on in date to determine if the correct version of event is installed or not (event_zonelist_by_name) and that is all. And since event never uses the timezone name except as a display, we don't have to worry about updating the event_timezones table to get rid of spaces. Very much better way to go... I have re-rolled the patch, only 4k and most of it because the additional indent causes whitespace differences. I have tested it first with just event installed and then adding the date module, and also with just date installed and adding the event module. I think it is good to go... Changing it to critical, as I would really like to see these two modules work together...

liveoutloud2day

karens’s picture

karens commented

One small change, change (variable_get('date_api_version', 0) == '5.2') to (variable_get('date_api_version', 0) >= '5.2')

We won't always be using version 5.2 :)

liveoutloud2day’s picture

liveoutloud2day commented
StatusFileSize
new event-date.diff4.04 KB

Chasing dev, and made the changes Karen suggested. Works with the 8/19/2008 version of event 5.x-2.x-dev module.
The corresponding issue in the date module is at http://drupal.org/node/240156

karens’s picture

karens commented
Status: Needs review » Fixed

This is no longer needed. I found a way to work around the conflict in the Date module by using after_build to come behind the Event module and make the necessary changes.

So no changes are needed to the Event module any more.

I marked it 'fixed' instead of "won't fix" or "closed" so people can find this issue in the queue.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

guillaumeduveau’s picture

guillaumeduveau
Location Toulouse
commented

For those having this problem, it indeeds seems to be fixed in Date 6.x-2.x-dev.