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!
Comment | File | Size | Author |
---|---|---|---|
#17 | 918830-unintended-side-effect.patch | 838 bytes | solotandem |
Comments
Comment #1
Dane Powell CreditAttribution: Dane Powell commentedSame issue, 6.x-2.6. Only Date, Date Timezone, Date Popup, and Date API enabled (in terms of date modules).
Comment #2
kapep CreditAttribution: kapep commentedAccording 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?
Comment #3
KarenS CreditAttribution: KarenS commentedIf 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.
Comment #4
Dane Powell CreditAttribution: Dane Powell commentedAny 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
Comment #5
kapep CreditAttribution: kapep commentedI 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).
Comment #6
markhalliwellI 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 :
Comment #7
KarenS CreditAttribution: KarenS commentedIf 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.
Comment #8
danmed CreditAttribution: danmed commented+1 in that exact same situation. Would like to know if a fix in Domain Access can be expected.
thanks
Comment #9
agentrickardYou 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.
The problem is caused by
date_api_form_system_date_time_settings_alter
which adds this at the bottom: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.Comment #10
agentrickardIf 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.
Comment #11
agentrickardSee in particular, the attachements to http://drupal.org/node/940804#comment-3577600
Comment #12
marktargett CreditAttribution: marktargett commentedChange it here for all domains
../admin/build/domain/batch/date_default_timezone
Comment #13
Rob C CreditAttribution: Rob C commented@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.
Comment #14
marktargett CreditAttribution: marktargett commentedi disabled the date api and everything seems good
Comment #15
lpalgarvio CreditAttribution: lpalgarvio commented+1
need a proper fix
Comment #16
Jegan2668 CreditAttribution: Jegan2668 commentedAny guidance for this is issue.?
Comment #17
solotandem CreditAttribution: solotandem commentedThe 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:
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:
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.
Comment #18
tim.plunkettI 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