Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
when admin add a new user I get:
Notice: Undefined index: timezone in date_field_validate() (line 330 - C:\wamp\www\mysite\sites\all\modules\date\date.field.inc).
Whats wrong?
Thanks.
Comment | File | Size | Author |
---|---|---|---|
#41 | date-undefined_index_timezone_1392472-41.patch | 1.31 KB | steinmb |
| |||
#22 | date-undefined_index_timezone_1392472-22.patch | 1.48 KB | Taran2L |
#9 | unidentified_index_error-1392472-5.patch | 746 bytes | rcaracaus |
#1 | IssueID_#3441_fix_it_and_create_patch_to_http___drupal_org_node_1392472.patch | 749 bytes | euginewm |
Comments
Comment #1
euginewm CreditAttribution: euginewm commentedPlease see my patch.
Comment #3
jjmackow CreditAttribution: jjmackow commentedThis issue is also occurring when a new registration is created by an anonymous user. I'm using Profile2 as well, but I do not have any date fields in any of my profile types. Perhaps Profile2 is a red herring but I'll try to disable it and see if the issue continues.
I can see that $items is getting passed into the function date_field_validation() function and that it the failure is coming from a call to:
line 330: $date1 = new DateObject($item['value'], $item['timezone'], date_type_format($field['type']));
How can I trap which module is calling the date_field_validate() function?
Comment #4
jjmackow CreditAttribution: jjmackow commentedAn update: on line 330, $item['timezone'] is being passed a value of
[timezone] => America/New_York
but when this value is changed to "GMT", I am able to have an anonymous user create a registration. I still don't know where Timezone is coming from since I do not have any date fields in my profile
Comment #5
jjmackow CreditAttribution: jjmackow commentedI've temporarily fixed my issue by changing the following on line 328 of date.field.inc:
from
if (is_array($item) && isset($item['value'])) {
to
if (is_array($item) && isset($item['value']) && isset($item['timezone'])) {
Comment #6
s_u_s_a_f_o_n CreditAttribution: s_u_s_a_f_o_n commentedThaks for an inspiration, i have fixed that issue by adding following code:
if (!isset($item['timezone'])) $item['timezone'] = date_default_timezone_get();
Comment #7
jkaine CreditAttribution: jkaine commentedS_u_s_a_f_o_n,
Where did you add this line of code?
Thanks,
JK
Comment #8
KarenS CreditAttribution: KarenS commentedThere is no patch so this is not 'needs work'. I can't do anything about this without information about how to reproduce the problem on a clean install.
Comment #9
rcaracaus CreditAttribution: rcaracaus commentedI was getting the same error and I fixed the module with the info from comment #5 I have created a patch.. tell me if it works...
If it is your first time using a patch go here:
http://drupal.org/project/date/git-instructions
Comment #10
kalabroI has the same notice in these situations:
Result: Notice: Undefined index: timezone in date_field_validate() (line 344 of /vhosts/test.home/sites/all/modules/date/date.field.inc).
Article created with date field setted to current time.
Comment #11
KarenS CreditAttribution: KarenS commentedNo one yet has told me how to reproduce the problem. I don't see this error.
Comment #12
kalabroHow to reproduce:
You will see notice and article will be created with date field setted to current time. I have strange problems with my custom AJAX, too. But everything works with alpha3.
Comment #13
KarenS CreditAttribution: KarenS commentedThis looks like the same underlying problem as #1359464: Date field in user profile show error if hidden. I just committed a fix for that and I don't see any error here.
Comment #14
kalabroThank you! It completely solved the problem.
Comment #15
ntigh52 CreditAttribution: ntigh52 commentedThank you Karen ! It completely solved the problem, on rc2 !!!!
Comment #17
szantog CreditAttribution: szantog commentedIt seems, there should be other cases, when $item['timezone'] is not built yet:
I have a form with date field, and some other fields, which use ajax. During the ajax processing the validation is called. I haven't idea what is the best way to fix, but insert
$item['timezone'] = isset($item['timezone']) ? $item['timezone'] : date_default_timezone_object();
before new DateObject is called solved this.
Comment #18
izus CreditAttribution: izus commentedexperienced the same issue with 2.6 version
Comment #19
podarokstatus for bot
Comment #21
Taran2LI can confirm #17. When form uses ajax, this PHP notice occur.
Comment #22
Taran2LComment #23
vijaycs85Lets add some test to cover this warning.
Comment #24
vijaycs85Comment #25
Antoine_k CreditAttribution: Antoine_k commentedThanks #22 worked perfectly for me!
Comment #26
jvandooren CreditAttribution: jvandooren commentedPatch #22 also fixed this issue for us. Can someone evaluate this patch and see if it can be committed?
Comment #27
podarok#22 looks good for me. RTBC for this part.
Agree with #23 - before committed this part of code should be covered by tests. Anyone?
Comment #28
jeff h CreditAttribution: jeff h commentedThis patch worked for me. It fixed a PHP warning I was getting about the timezone not being set when using entity metadata wrappers to set a date field.
Comment #29
podarokstill needs test before merging in...
Comment #30
Taran2LWilling to write a test, but now can't reproduce it ... Anyone to help?
Comment #31
FluxSauce CreditAttribution: FluxSauce commentedI can reproduce this when migrating content to a date field and I ignore the :timezone destination.
Comment #32
maen CreditAttribution: maen as a volunteer commentedfixed my warning too!
Comment #33
solotandem CreditAttribution: solotandem commentedI tested this with release 2.9 and the latest 2.x code which includes six more commits (latest on 2016-01-08). I find no warning with the 2.x code, but can 'trigger' it with the 2.9 code under specific conditions. In my case, I narrowed down the cause to the following flow:
elseif (!form_get_errors())
blockif (!form_get_errors())
condition is now satisfiedThe above-mentioned condition in date_combo_validate() was replaced in this commit by an else condition so that the $item array is always built out.
Given this issue was created four years ago, a lot may have changed in date module. The various comments suggest to me the error was occurring under certain conditions (as in my use case outlined above) but not generally; and the conditions were not identified (to wit Karen could not reproduce the warning). Unless someone can produce a use case under which the error occurs using the latest release, it would seem this issue has been resolved by the commit referenced above.
Comment #34
nickonom CreditAttribution: nickonom commentedThe patch in 22 gives hunk in PHP 7.0.8:
but still take cares of the error message. RTBC.
Comment #35
anrikun CreditAttribution: anrikun commented+1 for patch #22 RTBC
Comment #36
vijaycs85I can't reproduce the warning. As per @solotandem on #33, the warning has been fixed already. If you can still get warning, please provide steps to reproduce please? @anrikun or @nickonom?
Comment #37
JvE CreditAttribution: JvE as a volunteer commenteddate_field_validate()
(and perhaps other code) expects items to have both a "value" and a "timezone" key.This "timezone" info is added in
date_field_presave()
which is not called until the entity is saved.So any time you set a date field value with EntityMetadataWrapper (or another programmatic way) you will have an entity without a timezone until it is saved.
Solution 1: don't depend on "timezone" being present in
date_field_validate()
(which is what patch #22 does)Solution 2: add the "timezone" in
date_entity_metadata_struct_setter()
Comment #38
JvE CreditAttribution: JvE as a volunteer commentedComment #39
ultrabob CreditAttribution: ultrabob commentedComment #41
steinmb CreditAttribution: steinmb as a volunteer commentedManual re-roll. Did not test it. Can anyone that see it tell me how to re-produce this notice?
Comment #42
joelpittetThanks @steinmb, I was able to reproduce the error in my local environment and noticed it in my logs. This patch indeed fixes the issue.
Comment #43
joelpittet@steinmb the steps I have is that I have a date field that is hidden through field_permissions on a page that is using node_authlink.
LMK if you need more context.
Comment #44
lazzyvn CreditAttribution: lazzyvn commentedI have the same probleme with date default empty
i think must be check !empty($item['value'])) NOT isset($item['value'])
here is my patch
Comment #45
DamienMcKenna@lazzyn: That looks like a reasonable change. However, would you please open a new issue and cross reference it rather, than adding to an issue that's already RTBC? Thank you.
Comment #47
DamienMcKennaCommitted. Thanks!