Conflict between Event and Date API

Should be fixed now. Sorry!

Not to be the bearer of bad tidings, but I am still having this issue, using this rc

Did you did a fresh install or did you update from date 5.x-1.x?
In case you have updated from an old version try running update.php (this fixed it for me).

hth,

Stefan

I did a fresh install in this case (just installed it yesterday)

I had the same problem and I can confirm that this has been fixed.

SamRose: you have to download the latest dev release (5.x-2.x-dev). 5.x-2.0-rc has been released almost a month ago and doesn't contain recent bugfixes.

thanx, wwalc

Ok, I have uninstalled, re-installed from CVS 5--2 (5.x-2.x-dev), ran update. Unfortunately I am still experiencing this issue.

I encountered the same issue with the latest 5.x-2.x-dev version, fresh installation. There may be some unexpected factor. I will try again without setting a timezone before enabling the module.

When I have a chance I am going to try and look at the code and see why there would be a recurring bug here (diff from last change), because it definitely exists.

Are you using GMT ?
Try using UTC instead and set it again if you get an error the first time. (I don't know why, but I have to.)
Also, make sure it is set in your user's account as well as for the site.
I can reproduce it not working for GMT in D6.2 using the latest versions of CCK and Date, but it does work for UTC and some other timezones I tried.

Please confirm exactly what message is seen when. The latest dev code does not even contain the original message any more, so that can no longer be the problem if you're using the latest dev code, but there are other messages about timezones that you might see in other places.

Also, confirm that you actually *did* set a site timezone. You will see messages about that in various places until you set it because it's critical that it be set. And go ahead and submit the page even if you see the right timezone showing to be sure it's saved.

Have the same issue with the HEAD-Version of date and drupal 6.2. :(

The exact message is: "The Date Timezone module requires you to set the site timezone name."
The message can be found in date_timezone.module:

function date_timezone_init() {
  $tz_name = variable_get('date_default_timezone_name', NULL);
  if ($_GET['q'] != 'admin/settings/date-time' && (empty($tz_name) || $tz_name == 'GMT')) {
    drupal_set_message(t('The Date Timezone module requires you to !link.', array('!link' => l(t('set the site timezone name'), 'admin/settings/date-time'))), 'error');
  }
}

• I have the latest versions of CCK & Date as of Apr 15th.
• I can reproduce the error simply by setting the timezone to GMT and saving the configuration twice —the first time there is no error, but on saving it again I get the error message.

If you have that in your code, you are not using the dev version. This was changed in http://drupal.org/cvs?commit=108910 on April 3. Get the latest dev version and you should not have any more problems.

@ MartinSfromB - You are posting on an issue for the 5.2 version. HEAD is pointed at Drupal 6 and is unfinished and will need completely different fixes anyway, so you have to use separate issues for that version.

You are right--the code I posted was from HEAD, not from 5.2
Sorry for posting on the wrong issue queue

I have the 5.x-2.x-dev version and the date_timezone.module with $Id: date_timezone.module,v 1.8.2.6 2008/04/03 10:32:29 karens Exp $. The message is in function date_timezone_menu.

I still have the problem: The message never goes away, no matter how many times I set a timezone. It appears in most pages.

Another observation: When I disable the module the message goes away, but the list of available timezones in admin/settings/date-time still contains the *named* timezones and does not return to the explicit timezone formats.

I am on PHP 5.2.1, fresh Drupal 5.7 installation, and the only date-related thing I did before enabling the module was to set the timezone and date/time formats for user #1 and for the site to European ones (Default time zone: Tuesday, 15 April, 2008 - 20:10 +0200).

Ah!!! Thanks Karen, you gave me the clue which enabled me to get things working.
I was using HEAD, thinking I was using the latest version, but because of some missing tagging, HEAD is old (March 12)
When I used CVS instead of head, some of my problems started to get resolved.

@cog.rusty, if you see timezone names when the module is disabled, they are getting put there by some other module. What other modules are you using? If some other module is altering that form, you'll definitely have problems.

Got it! It must have been some conflict with the event module (5.x-2.x-dev 2008-04-16).

Keeping the date_timezone module enabled, I disabled the event module and uninstalled it and the message went away.

I enabled the event module again, then I had to update the timezones again, but the error did not reappear so far. (Perhaps order of installation matters.)

Ack! This is going to be a problem. Turns out both Date API and Event module are trying to overload the timezone forms. I need to file an issue over there so we can find a way to avoid the conflict. The reason you were able to work around this by changing the order is that once the Date value was set it quit sending the message, but if you ever tried to change that value or if you are using user-configured timezones, you'll run into it again. The Event module wins the race -- it comes later in the alphabet so its changes to the form stick and the Date module's changes get lost.

See http://drupal.org/node/247959 for my Event issue.

And this is critical.

Ah, no wonder you thought it was fixed :) . You'd have to have the event module enabled to see this bug. Thanks KarenS

subscribing

subscibing

Just bumping this issue so people can find it. Still no resolution, so at the moment Event and the Date API are still incompatible.

subscribe

OK ... I think I found the problem. In system.module (at least for Drupal 5.7) the system variable is called

date_default_timezone

not

date_default_timezone_name

so the $tz_name variable is always NULL.

I've attached a patch that fixes the problem for me.

Hrm ... the patch isnt attaching. Trying again. Also, looks like there are 3 equal signs in the test in the .install code. Fixed that as well.

That won't work. If the Event module was not interfering you would have the right variable available. The system variable is the timezone *offset* not the timezone *name*. I cannot fix this in the Date module, it can only be fixed by disabling the Event module or by getting a fix into the Event module.

I would also like to use both event and date api v5.2 for rsvp, resource on the event side and date_popup fields on the date side of things. I was able to code a patch to make this work. It is based on date v5.2-rc6 and event 5.2-dev (july-16-2008) only changes one function on the date side, by adding 3 lines basically to jump around the date_timezone_update_site function if event is installed.

I think event shows up later in process, not just because of the fact E comes after D, (that could be changed by setting the weight of the modules in the system table), but because event uses an interesting way to add the submit function to the end of the submit in hook_alter:

      $submit['event_extra_setting_form_submit'] = array();
      $form['#submit'] = $form['#submit'] + $submit;

I think that overrides everything, but not sure. Anyway I changed a few things over there.

So here is 2 files - a patch file of the date module, and the event module I am using. I am including that here, as it is impossible to know when something might change in the event module dev version and no official release of the 2.x version yet. So a patch file may not apply twenty minutes from when I submit this.

Concerning the patch file for date it is based off of 5.x-2.x-rc6, a particular release, applied with a patch -p0 <date-event.diff from the modules directory.

As mentioned in comment #22 the event side of this is at http://drupal.org/node/247959 where I will be explaining what I changed in the event module.

Hope it helps!

liveoutloud2day

Oops, the event module wasn't quite right on new installs. This one does the underscore fix on install if necessary. Update 5200 could always be run manually, but... here is the updated gzipped tar file.

liveoutloud2day

I just committed a different fix that will update the Event module values if the Event module leaves the timezone form alone. As I note on the related issue on the Event module queue, this will be the least disruptive solution for both modules. There is no need for the Event module to change its timezone names, run updates, or update Date module values.

I'm leaving this active until the related patch gets committed in the Event module.

I will go ahead and submit the patch on the event module when I get it going - however, I don't think it is going to work because of what I said about the your module using hook_validate vs. event using form_alter($op=submit) with the modification to the submit at the end of it. Not sure which is the correct way....

Oh - I can just skip the submit part with my if statement - didn't think of that.... Anyway, I have submitted the patch over at http://drupal.org/node/247959#comment-970013 - I bumped it up to critical, since the patch is there, not an empty feature request. If you wanted to go over and grab it and test and if it works mark it as RTBC, it might speed it along... Thanks.

Bump this ahead, it is still a problem in D6.

I made your suggested modifications over at http://drupal.org/node/247959#comment-1012418 and submitted a new patch. Thanks for the thorough review of it, maybe a RTBC is in order over there? Thanks! liveoutloud2day

I figured out a work-around for this problem and have committed it. I changed the processing to add a #process item to the form which lets me process the timezone forms after Event module is finished with them so I can make the changes I need to make. I added in a date version of the function to grab the Event module timezone value out of the database, so I won't need the event module to create that, and I make sure the Event module gets back the form values it expects after I get done with them.

It looks like this works without any need for changes to the Event module, so we can close the Event module patch.

We will need to keep an eye on this to be sure it doesn't break the Event module anywhere, but now that I figured out how to work around this, I should be able to fix any other problems without any need to patch the Event module.

Spoke too soon. It's working fine in the D5 version, but FAPI works different in D6 and the things that worked in D5 aren't working in D6, so I have to get that figured out.

OK, now I found a way to get this working right in D6, too. So I have now removed the conflict between Date and Event and you can use them together with no need for further changes in the Event module.

In fact, I *don't* want any changes to the event module now, since I wrote this code that assumes it will work the way it works now.