When trying to save any changes of the Locale settings of the Date and Time configuration it will reset to defaults after the page reloads: Default time zone is blank, User-configurable time zones enabled, Sunday.

Got issue first with 6x-2.6, changing to -dev version didn't solve the problem. Reinstalled -dev and only activated Date API and Date Timezone.

Gone though all troubleshooting steps, searches revealed some old issues caused by the event module which I don't have installed nor any other date related modules (as far as I know - are there any known conflicts with other common modules?)

So I can't change the time zone, Drupal is using UTC/GMT I think, the servers PHP default time zone is set to Europe/Berlin.

Thanks!

CommentFileSizeAuthor
#17 918830-unintended-side-effect.patch838 bytessolotandem
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dane Powell’s picture

Same issue, 6.x-2.6. Only Date, Date Timezone, Date Popup, and Date API enabled (in terms of date modules).

kapep’s picture

Priority: Normal » Major

According to the priority description this should be something other than normal. Major or critical? I think I'll change to major for now (The whole module is not usable).

I've notices the Domain module I'm using has it's own time zone settings. Maybe that is causing errors with the date configuration page?

KarenS’s picture

Status: Active » Postponed (maintainer needs more info)

If you're using some other module that sets timezones, there is nothing I can do about that. I would post an issue on the Domain module queue. The date module is pretty widely used, it would make sense for the Domain module to either use the Date timezone handling or do it in a way that won't clobber Date.

This works fine if you use only Date and Drupal core, so if there's a problem it's a conflict with some other module.

Dane Powell’s picture

Any suggestions on how to go about uncovering that conflict? I don't have the Domain module installed- in fact I have a very small number of fairly standard modules, none of which should interfere with Date AFAIK

kapep’s picture

I deactivated Date time zone and checked the domain access module again: It seems to deactivate the standard date and time configuration (at least the timezone dropdown is deactivated).
I think domain access is mainly at fault here. There should be some information why it is deactivated.

Is it possible/reasonable for the time zone module to check if the configuration page was deactivated or altered by other modules before rewriting the form (and thus giving the impression it is still working)?

@Dane Powell
You too should try to see if the configuration works without date time zone module. Maybe it is the same problem (just caused by some other module).

markhalliwell’s picture

Status: Postponed (maintainer needs more info) » Needs work

I recently also had this problem with my site and saw that you mentioned Domain Access. This made me think and I found that Domain Access is indeed the culprit, causing Date API to not save properly. Looks like how Date API saves it's variables needs to be redesigned or at the very least add support for Domain Access.

#3 of #940804: Default Time Zone :

Since this form requires special handling, it should be disabled from Domain Settings. Add this line to 'Disallowed forms':

system_date_time_settings

KarenS’s picture

Project: Date » Domain
Component: Date Timezone » Miscellaneous
Status: Needs work » Active

If domain access is breaking the Date module, it is not a Date bug, Domain Access that needs to do something about it. Date is used on 120,000 sites, Domain Access on only a very small portion of them. You should start by reporting the problem there and have them find a way to do whatever they are doing without breaking this module.

The Event module also tries to set timezones. I deliberately made my changes in an after_build to avoid breaking that. But I can't rewrite the module around every and any way that other modules might try to alter timezones.

Fortunately timezone handling got into core for D7 so we won't be battling over ways to control it after that.

danmed’s picture

+1 in that exact same situation. Would like to know if a fix in Domain Access can be expected.

thanks

agentrickard’s picture

Project: Domain » Date

You have it backwards. Date module re-introduces 'system_settings_form_submit', which core deliberately removes.

This only affects the Domain Settings module. The solution for which is to not process the form if Date is enabled.

Domain Settings works by making domain-sensitive any form that features a system settings form that does _not_ require additional processing.

function domain_settings_form_alter(&$form, $form_state, $form_id) {
  global $_domain;

  // Remove settings that cannot be used reliably.
  $disallow = domain_settings_disallow();
  if (!user_access('access domain settings form') || in_array($form_id, $disallow) || !isset($form['#submit']) || !in_array('system_settings_form_submit', $form['#submit'])) {
    return;
  }
// ...

The problem is caused by date_api_form_system_date_time_settings_alter which adds this at the bottom:

  $form = system_settings_form($form);

This call is _deliberately_ not in core, and I don't know why it's here. Removing that may solve the problem, but then you might need your own submit handler to save the variable.

The settings are in fact saved, they just can't be made domain sensitive.

Given the way hook_form_alter() works, there is nothing to be done on the domain side here except for writing a very nasty exception rule if date_api_form_system_date_time_settings_alter exists, and that's not The Drupal Way.

agentrickard’s picture

If you prefer, you can mark this a duplicate of #940804: Default Time Zone and point people there. This is a known issue that has to be solved by Date or worked around by adding a very simple line to the Domain Settings configuration.

agentrickard’s picture

See in particular, the attachements to http://drupal.org/node/940804#comment-3577600

marktargett’s picture

Change it here for all domains
../admin/build/domain/batch/date_default_timezone

Rob C’s picture

@marktargett #12

True, but the error on the status page remains and on the config page of the date format, changes can not be seen.

marktargett’s picture

i disabled the date api and everything seems good

lpalgarvio’s picture

+1
need a proper fix

Jegan2668’s picture

Any guidance for this is issue.?

solotandem’s picture

Status: Active » Needs review
FileSize
838 bytes

The explanation by agentrickard is correct. I have tested the attached patch with and without the domain settings module enabled. This patch simply deletes the line referred to in #9 as it is included in core:

  $form = system_settings_form($form);

Also, to clarify the later comment in #9, the date-time settings form in the system module includes this code which has been in effect since August 2007:

  $form = system_settings_form($form);
  // We will call system_settings_form_submit() manually, so remove it for now.
  unset($form['#submit']);

The removal of the settings form submit handler in the last line above is what the domain settings module keys on to not attempt to save domain specific settings.

tim.plunkett’s picture

Status: Needs review » Fixed

I just had the same problem with D7 and came up with the same solution. Committed to both branches.

http://drupalcode.org/project/date.git/commit/af32556
http://drupalcode.org/project/date.git/commit/36b2066

Status: Fixed » Closed (fixed)

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