Download & Extend
Date » Issues

date_timezone_set() & date_format() error when editing CCK date repeating fields.

Posted by likewhoa on March 21, 2009 at 4:50pm
Project:Date
Version:6.x-2.1
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:closed (fixed)

Issue Summary

I am using latest drupal-6.10 with -dev cck and while editing node with the cck date field I get this error below and now views won't pick up the date.

* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 654.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 654.

Login or register to post comments

Comments

#1

Posted by likewhoa on March 21, 2009 at 7:28pm
Status:active» closed (fixed)

i can't reproduce this on another boxen, closing so i can fix.

#2

Posted by prhodes on March 23, 2009 at 3:19pm

I am having the same issue, just refreshed my Date API module and it started happening.
Date Repeat API 6.x-2.x-dev
Date API 6.x-2.x-dev

Digging into it, but I think 2 folks having an issue at the same time may indicate a problem somewhere

* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /sites/all/modules/date/date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in /sites/all/modules/date/date_api_ical.inc on line 654.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /sites/all/modules/date/date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in /all/modules/date/date_api_ical.inc on line 654.

#3

Posted by prhodes on March 23, 2009 at 3:23pm

Disabling the Calendar iCal 6.x-2.0 does not fix the issue.

I am not setting any repeat options, so I am not certain if this has anything to do with the issue.

#4

Posted by bernadotte on March 23, 2009 at 5:45pm

same problem.
yesterday, everything worked well. today i tweaked some views and all in a sudden, the events are not shown in the day view (but only existing ones, new ones get displayed)
but and i get the same errors on posting and editing events.
ical is not and was not enabled.

#5

Posted by prhodes on March 23, 2009 at 5:59pm
Status:closed (fixed)» active

Added the following to date_api_ical.inc , line 563 to print out the ical_date, following is the result

drupal_set_message ("" . print_r ($ical_date));

This is what comes on screen. Is there a way to get "print_r" to not close a response?
Array ( [datetime] => [tz] => America/New_York [all_day] => 1 [granularity] => a:3:{i:0;s:4:"year";i:1;s:5:"month";i:2;s:3:"day";} ) Array ( [datetime] => [tz] => America/New_York [all_day] => 1 [granularity] => a:3:{i:0;s:4:"year";i:1;s:5:"month";i:2;s:3:"day";} )

On an unrelated note, how would you (a more experienced drupal developer) would have gotten this info? print_r doesn't seem to like to print to the drupal_set_message string since it kills the rest of the screen.

#6

Posted by prhodes on March 23, 2009 at 6:06pm

Sorry for posting this again, here is my variable, with pre tags, so it's formatted. One can see the datetime is null in the array.

Array
(
[datetime] =>
[tz] => America/New_York
[all_day] => 1
[granularity] => a:3:{i:0;s:4:"year";i:1;s:5:"month";i:2;s:3:"day";}
)

Array
(
[datetime] =>
[tz] => America/New_York
[all_day] => 1
[granularity] => a:3:{i:0;s:4:"year";i:1;s:5:"month";i:2;s:3:"day";}
)

#7

Posted by prhodes on March 23, 2009 at 6:11pm

#8

Posted by lonelyrobot on March 24, 2009 at 6:34pm

Oops.... DON'T USE THIS

AttachmentSizeStatusTest resultOperations
date-409476.patch811 bytesIgnored: Check issue status.NoneNone

#9

Posted by arlinsandbulte on March 24, 2009 at 7:28pm

Steps I can use to reproduce this issue:

  1. Clean install of Drupal 6.10
  2. Enable CCK - Content (6.x-2.2)
  3. Enable Date - Date, Date API, Date Popup, Date Repeat API, & Date Timezone (6.x-2.x-dev 2009-Mar-23)
  4. Manage Fields of Story, adding New Field; Label: Date, Field Name: date, Data Type: Date, Form Element: Text Field with Date Popup and Repeat Options
  5. Make To Date optional and Save (leave all other settings at default).
  6. After setting the default timezone at http://localhost/admin/settings/date-time to America/Chicago
  7. Create a Story, ONLY fill in the Title and Body Fields. Leave all else at the default (date fields are left blank).

* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in \sites\all\modules\date\date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in \sites\all\modules\date\date_api_ical.inc on line 654.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in \sites\all\modules\date\date_api_ical.inc on line 568.
* warning: date_format() expects parameter 1 to be DateTime, null given in \sites\all\modules\date\date_api_ical.inc on line 654.

#10

Posted by lonelyrobot on March 25, 2009 at 5:34am

This one seems to be working.

AttachmentSizeStatusTest resultOperations
date-409476.patch1.64 KBIgnored: Check issue status.NoneNone

#11

Posted by srjosh on March 26, 2009 at 7:03pm
Version:6.x-2.x-dev» 6.x-2.1

I'm also seeing this behavior. Just started this morning after I upgraded to March 25th release.

EDIT: Further info

It only happens when I am saving a node with event dates but no repeat rules. If I define repeat rules, then it saves just fine.

I can provide export of view if needed; email me.

srjosh

#12

Posted by lonelyrobot on March 26, 2009 at 11:03pm

Rerolled for 6.x-2.1 (and slightly modified). Deals with NULL value for UNTIL getting passed to date_api_ical_build_rrule (doesn't attempt to add the rule if the value is NULL). Also makes sure _date_repeat_widget_validate() cleans up the form before returning (otherwise date_field throws a bunch of errors when building additions).

AttachmentSizeStatusTest resultOperations
date-409476.patch1.43 KBIgnored: Check issue status.NoneNone

#13

Posted by Bremen Saki on March 27, 2009 at 1:09am

I'm getting this in a slightly different context but I guess it would be the same root cause with null dates.

We have a radio show content type, with a show profile and a schedule for that show. I'm using content permissions so the DJs can put in their show details without the date fields visible and confusing their poor brains, and a separate group is in charge of putting it in the right spot in the schedule. So when a show is created, it never has any start date, end date or repeat rules.

This works fine but the errors mentioned pop up on various pages when a show with no scheduled time exists, which is the default state for all of them.

I can sort of live with it in the sort term, since new shows get scheduled pretty quickly, but it'd be nice to know if this circumstance is something that SHOULD work or if it's totally insane and I need to rethink the whole approach.

#14

Posted by gorcon on March 27, 2009 at 3:35pm

Seeing identical behavior with 6.x-2.1 (just upgraded this morning). Although I get a list of warnings when I save the node, the node still appears as I would expect in my calendar view.

#15

Posted by lonelyrobot on March 28, 2009 at 6:22pm
Status:active» needs review

Changing the status.

#16

Posted by mreyher on March 31, 2009 at 5:05pm

Same error here... will turning off iCal supress the errors until there is a fix?

#17

Posted by lonelyrobot on March 31, 2009 at 7:37pm

Has anyone tried the patch in comment #12? Does it not work? This has fixed the issue for me.

#18

Posted by robbieferrero on March 31, 2009 at 11:13pm

I was having the same issue. I went to my content type, to Manage Fields, Configured my Date field, then changed the Widget type to not have a Repeat Option. That cleared the errors.

Obviously this isn't ideal as the repeat function would be helpful, but for now this will work (for me anyway).

#19

Posted by tekknogeek on March 31, 2009 at 11:32pm

Hello, I am running the latest Date API 5.x-2.x-dev and I am experiencing similar issues with a node type containing null repeating date fields. Could the patch in #12 be adapted to fix the warnings in 5.x? I am getting the following warnings:

* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 570.
* warning: date_format() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 656.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 570.
* warning: date_format() expects parameter 1 to be DateTime, null given in /modules/date/date_api_ical.inc on line 656.

The code being modified in the second half of the patch in comment #12 seems to be identical in the 6.x and 5.x versions.

Thank you.

#20

Posted by peggysmouse on April 1, 2009 at 7:57pm

@12

i couldn't apply the patch in the usual way but i did manually applied them which cleans up the error.

thanks.

#21

Posted by philsward on April 2, 2009 at 4:25am

In response to comment #16, I have not enabled ical at all, and still received the error...

#22

Posted by Hoople on April 2, 2009 at 5:20am

Thanks for the patch. When will date 2.2 be released with this fix in it?

#23

Posted by blackdog on April 2, 2009 at 2:46pm
Priority:normal» critical
Status:needs review» reviewed & tested by the community

Patch in #12 works great!

#24

Posted by KarenS on April 2, 2009 at 4:57pm
Status:reviewed & tested by the community» postponed (maintainer needs more info)

I'm not sure about the form_set_value() in the patch. What happens if you leave that out? I'm worried that it won't work correctly for all types of date fields in all the many possible ways they could be configured.

#25

Posted by sbayne on April 2, 2009 at 5:28pm

The patch in #12 fixed it for me as well.

#26

Posted by KarenS on April 2, 2009 at 6:08pm

Unless someone answers the question I answered in #24, saying that the patch in #12 fixed it won't get us anywhere and the patch won't get committed.

#27

Posted by KarenS on April 2, 2009 at 6:09pm

Er, the question I *asked* in #24.

#28

Posted by lonelyrobot on April 2, 2009 at 7:51pm

if you remove that line, the patch does not work. it will get rid of the errors targeted by this issue, but if you set the frequency and leave the Until blank, you will get errors at the following lines:

# warning: Cannot use a scalar value as an array in /home/tripark/drupal6-common/sites/all/modules/date/date/date.module on line 452.
# warning: Cannot use a scalar value as an array in /home/tripark/drupal6-common/sites/all/modules/date/date/date.module on line 453.
# warning: Cannot use a scalar value as an array in /home/tripark/drupal6-common/sites/all/modules/date/date/date.module on line 454.

You could remove the following code surrounding that line completely from the patch:

if (form_get_errors()) {
    $form_values[$field_name]['rrule'] = NULL;
    form_set_value($element, array($form_values[$field_name]), $form_state);
    return;
  }

and eliminate both sets of errors. But it would then perform some unnecessary work if the form is not being submitted because of the errors, since it would be building the repeat date using an invalid RRULE (at least invalid from the module's perspective). But removing this block of code from the patch may be the best option for now, if the line included in this block looks like it could cause trouble.

The lines

$form_values[$field_name]['rrule'] = NULL;
form_set_value($element, array($form_values[$field_name]), $form_state);

are the same ones are same ones found at line 67, which handles cleanup in the situation where the frequency isn't set, which made me think that it would also be safe to use when the UNTIL is missing. is this correct thinking?

#29

Posted by sharrison on April 2, 2009 at 10:26pm

Could someone tell me where I should cut in the patch?

I've never patched a module before, so I don't know where to place it....

Thanks for the help.

#30

Posted by david.sarnowski on April 3, 2009 at 6:15am

I could use some instructions on applying this patch as well!

Thanks

#31

Posted by blackdog on April 3, 2009 at 7:15am

@ #29 & 30: see http://drupal.org/patch/apply

#32

Posted by macrocosm on April 3, 2009 at 11:49pm

for those of you having trouble applying the patch upload the patch in #12 to your modules directory; and then from the command line use this...

sudo patch -p0 < date-409476_1.patch

The patch works perfectly by the way! Thanks for that!

#33

Posted by mariagwyn on April 6, 2009 at 9:20pm

I can confirm that the patch works, but I can't offer anything on whether it destroys other elements of the date functions.

#34

Posted by xmacinfo on April 7, 2009 at 12:05am
Status:postponed (maintainer needs more info)» needs work

Same for me, applied this patch in #12 successfully. I don't know Date enough to answer question #24 though.

I'm putting this to "needs work" just to clear out #24. ;-)

#35

Posted by giggler on April 7, 2009 at 3:15am

subscribing

#36

Posted by ShutterFreak on April 7, 2009 at 9:50am

Subscribing as I have exactly the very same problem when creating an "Event" content type with a Date field that can have a repeat rule. So far I only tested it with an entry having no repeat condition, upon which Drupal warns me with the 4 error messages below:

  • warning: date_timezone_set() expects parameter 1 to be DateTime, null given in C:\xampp\htdocs\sites\all\modules\date\date_api_ical.inc on line 568.
  • warning: date_format() expects parameter 1 to be DateTime, null given in C:\xampp\htdocs\sites\all\modules\date\date_api_ical.inc on line 654.
  • warning: date_timezone_set() expects parameter 1 to be DateTime, null given in C:\xampp\htdocs\sites\all\modules\date\date_api_ical.inc on line 568.
  • warning: date_format() expects parameter 1 to be DateTime, null given in C:\xampp\htdocs\sites\all\modules\date\date_api_ical.inc on line 654.

The versions I have, are: Drupal 6.10, CCK6.x-2.2, Calendar 6.x-2.1, Date 6.x-2.x-dev of 02-Apr-2009 (due to the 'now' filter problem in Date 6.x-2.1), Views 6.x-2.3

#37

Posted by likewhoa on April 7, 2009 at 11:07am

take a look at patch on comment #24.

#38

Posted by tirsales on April 7, 2009 at 12:42pm

subscribe

#39

Posted by amariotti on April 7, 2009 at 4:34pm

subscribing...

#40

Posted by arosemartin on April 7, 2009 at 8:32pm

Subscribing, I have this exact problem..

#41

Posted by georgedamonkey on April 7, 2009 at 11:42pm

subscribing

#42

Posted by jsimonis on April 8, 2009 at 3:40am

It says that the files were patched, but the error remains.

Could someone upload (or email me at jenni and the domain is forwardsupport.com) the patched files and I can see if maybe they're just not being patched properly?

#43

Posted by cletusalphonse on April 9, 2009 at 3:30pm

Subscribing, same issue here.

#44

Posted by snorkers on April 10, 2009 at 6:53pm

Is the said patch #12 now seen as the definitive solution and has #24 been answered? #28 seems to infer we need a completely different approach. I'm a little confused: what would anyone suggest for the short term: running with patch #12, or disabling repeat date options? Or is there a DEV re-roll in the short term?
Wish I really understood PHP more...

#45

Posted by pippal on April 10, 2009 at 11:53pm
Version:6.x-2.1» 5.x-2.6

#19 patch works with 5.x-2.6

#46

Posted by xmacinfo on April 11, 2009 at 3:07am
Version:5.x-2.6» 6.x-2.1

To answer #44, KarenS, the maintainer, is asking in #24 if the patch contributor in #12 can re-roll the patch and at the same time answer the question.

The patch in #12 works perfectly.

As for a new dev or any new release there will be eventually one made by KarenS.

#47

Posted by jerror.me on April 12, 2009 at 2:28am
Component:Code» Documentation
Category:bug report» task
Priority:critical» normal
Status:needs work» needs review

Possible Easy FIX!

Just wanted to add that this issue can also be caused by not setting a data time format type with a custom date format.
Example:
set your administer>site configuration>date and time>formats>configure>add format type>(make up a name)
if you have a
administer>site configuration>date and time>formats>configure>=(non-default setting)

Make sure you give it a name. Maybe it could be required on the form if you are changing the default values as some users may overlook the name field? (ie. me in a rush)

First post! Woot!

#48

Posted by j_ten_man on April 12, 2009 at 4:40am

subscribe

#49

Posted by xmacinfo on April 12, 2009 at 6:07am
Component:Documentation» Code
Category:task» bug report
Priority:normal» critical
Status:needs review» needs work

Correct bug tracking info.

#50

Posted by duran on April 13, 2009 at 8:53pm

subscribe.
would be nice to see this in a official release to solve whats kinda a big issue ...
thanks.

#51

Posted by gpk on April 14, 2009 at 7:01pm
Status:needs work» needs review

Changing status since Karen's questions at #24 have I think been comprehensively answered at #28, and it looks like further input is needed from Karen before this will progress.

#52

Posted by dvc9 on April 15, 2009 at 8:00pm

subscribing...

#53

Posted by David_Rothstein on April 15, 2009 at 11:46pm

I believe the attached patch fixes this bug in a cleaner way, without needing to mess with form_set_value().

Note that the PHP warnings described in #28 occur during the population of the $additions array in date_field(), but this array isn't even used during the form validation.... So my solution in this patch was to simply not bother defining the array except when it's actually needed, and then the PHP warnings never occur.

In fact, the PHP warnings are a totally separate bug, as far as I can tell -- they seem to occur in the latest -dev release of Date also (i.e., without applying any of the patches in this issue). Furthermore, if my analysis above is correct, they are really a very minor bug, since they occur during the definition of an array that never actually gets used for anything so they can't really have any actual consequences. So you could probably get away with just committing the date_api_ical.inc portion of the patch if you wanted and leave anything else to a followup issue, but I already went through the trouble of including it in the patch before I realized this, so I'm leaving it in for now :)

I'm slightly curious about why the warnings occur at all, though -- it has something to do with the $items array being in a different format than it otherwise would be, but I wasn't able to really track it down.

AttachmentSizeStatusTest resultOperations
date_repeat.patch2.59 KBIgnored: Check issue status.NoneNone

#54

Posted by xmacinfo on April 16, 2009 at 1:16am

Questions for #53.

Is your patch make against Date 2.1 or 2.x-dev? Have you tried the latest 2.x-dev and see if your patch still applies? If so, I think that the patch would have a greater chance of being committed against 2.x-dev.

Even if the warning messages bug is minor, we still need to fix this issue. We are currently unable to use Date on production web sites; clients are wary about these error messages. ;-)

#55

Posted by David_Rothstein on April 16, 2009 at 2:29am
Version:6.x-2.1» 6.x-2.x-dev

Yup, the patch was rolled against the latest dev version.

Also, to clarify, the warning messages that I identified as minor are those discussed in #28. The original warning messages that prompted this issue are certainly a much more serious bug. So basically, as long as you configure Drupal to not print error messages to the screen, the warning messages discussed in #28 shouldn't cause any problems at all, unless your clients are the kind of people who like to spend lots of time studying their watchdog error logs or something like that :)

#56

Posted by Levure on April 17, 2009 at 9:56am

subscribing...

#57

Posted by chey on April 20, 2009 at 4:46pm

The patch in #53 suppressed the errors I was getting and so does shutting off errors to screen as mentioned in #55.

If the until field is required then it should also have an asterisk next to it in the form but maybe there is another issue ticket already for that.

Thanks though...everyone here. I've been searching for an answer to this for a few weeks now.

Regards,
Chey

#58

Posted by GregoryHeller on April 21, 2009 at 4:41am

@47 I tried this method, to no avail. Errors persist. Are you sure this worked for you? and what do you mean by:


if you have a
administer>site configuration>date and time>formats>configure>=(non-default setting)

#59

Posted by jfeiler on April 21, 2009 at 10:03pm

I'm seeing it consistently on unlogged-in users but not authenticated users--anyone else?

#60

Posted by aharown07 on April 22, 2009 at 5:33pm

subscribing

#61

Posted by techtweaker on April 22, 2009 at 6:21pm

How do I "subscribe" to an issue, to follow up on it. Is commenting enough?

#62

Posted by Colorful Tones on April 22, 2009 at 6:24pm

subscribing

#63

Posted by snorkers on April 22, 2009 at 11:19pm

@techtweaker (+ all the other lurkers) - Drupal only gets better by the community making positive contributions. So yes, by adding a comment that says '+1' or 'subscribing' it appears in your issues queue (I did it myself without realizing the consequences)... but it means that everyone else who's made a comment sees that you've added a comment, albeit a worthless contribution to the module. So rather than just 'subscribing', if you're not an uber-coder (like me), at least report the errors you're having and maybe try out a patch - if you know how to do that. That way we can collectively resolve the issue rather than rely on the overworked maintainers.
*rant over*
And sorry to other subscribers who thought there was real news to report.

#64

Posted by aharown07 on April 22, 2009 at 11:46pm

@techtweaker....
It's a fair question. You have to learn somewhere.
Commenting will make show up in your Track tab in your profile. If you want emails, you can do that from the main module page (I think) or else the main issue queue. But when you sign up for email, you get pretty much all issue updates, not just one.

So my own habit has been to sign in and check my Track tab quite frequently.

As for "Subscribing" and "+1," it is a contribution because it lets module maintainers know, to some degree, how to prioritize based on how many people care about the issue. Not everyone can contribute code or test.

#65

Posted by glass.dimly on April 23, 2009 at 12:22am

Whew. All that said... +1.

#66

Posted by greggdickson on April 23, 2009 at 10:37am

+1

#67

Posted by becca08 on April 24, 2009 at 7:56pm

another +1

#68

Posted by aharown07 on April 24, 2009 at 8:58pm

@53 ... any chance you could reroll patch against the Apr 21 6x 2x dev? ... or 6x-2.1?

Otherwise, I can try to do a manual patch I suppose. It's not all that long.
Edit: not much luck doing manually... can't seem to match up parts of it.

#69

Posted by David_Rothstein on April 24, 2009 at 9:37pm

@aharown07: The patch in #53 already applies against both of those versions of the module.

Everyone: Testing would be great -- I don't think it's going to get committed without someone else trying it out or reviewing it :)

#70

Posted by aharown07 on April 25, 2009 at 12:57am

Will definitely give it a whirl & report shortly.

Edit... having trouble running the patch against 6x-2.1

can't find file to patch at input line 8

I've only applied patches once or twice so.. not sure I'm doing it right.
But I can verify that I do not have a date_api_ical.inc file.

Edit... Nevermind. Found it. Patching.

#71

Posted by aharown07 on April 25, 2009 at 1:58am

Patch is working for me.
One problem that may well be normal... I had turned repeating off in the widget to avoid the error. After applying the patch, I turned repeating back on in the widget, but the widget didn't actually change.

But when I added a new date field w/pop up & repeating widget, it worked fine. No errors.

#72

Posted by zeropaper on April 28, 2009 at 10:12am

#53 worked for me

#73

Posted by KarenS on April 29, 2009 at 12:01am
Status:needs review» postponed (maintainer needs more info)

I just committed some fixes which are different than any of the ones above that seemed to fix the problems, but there may be more than one problem here. So check the very latest -dev to see if there are still issues after my patches (I made a corresponding patch in the D5 version).

The problem I fixed (which caused the at least some of these errors) was trying to create a date with a null value, causing the PHP date_create() and date_timezone_set() code to protest. I took care of that by aborting any attempt to create a date when the datetime value is empty.

#74

Posted by fox 2 on April 29, 2009 at 1:02pm

I have just upgraded to the lastest dev version. All was fine until I tried to change the widget to include repeat events and then these errors appeared, so it appears the latest dev version just uploaded hasn't fixed the problem.

#75

Posted by fox 2 on April 29, 2009 at 1:06pm

the precise errors I now have are:

warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /home/sites/mysite/public_html/modules/calendar-6.x-2.1/calendar/includes/calendar.inc on line 414.
warning: date_format() expects parameter 1 to be DateTime, null given in /home/sites/mysite/public_html/modules/calendar-6.x-2.1/calendar/includes/calendar.inc on line 416.
warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /home/sites/mysite/public_html/modules/calendar-6.x-2.1/calendar/includes/calendar.inc on line 414.
warning: date_format() expects parameter 1 to be DateTime, null given in /home/sites/mysite/public_html/modules/calendar-6.x-2.1/calendar/includes/calendar.inc on line 416.

#76

Posted by fox 2 on April 29, 2009 at 1:15pm

ok if this helps anyone, I have fixed the problem I found. When changing the field back to having no repeating option, the Number Of Values remains as Unlimited. If this is changed manually back to 1 then the errors are gone :)

#77

Posted by reaneyk on April 29, 2009 at 9:22pm

subscribing

#78

Posted by 11thfinger on April 29, 2009 at 11:14pm

I'm getting a different file and line number than the folks above. Whenever I add more than 2 fields, I get the following:

warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /var/www/vhosts/cat3.tv/httpdocs/sites/all/modules/date/date/date_elements.inc on line 229.

Each time I add a new field. I've updated to the latest dev version as of today, but it doesn't appear to be fixed.

#79

Posted by profix898 on April 30, 2009 at 7:56am

I can confirm the issue as reported by 11thfinger in #78 using the latest Date (and CCK) -dev version.

"warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /var/www/igsm/www/dev/sites/all/modules/date/date/date_elements.inc on line 229."

This is a serious issue because we cant use the release version of Date on a productive site atm. I really hope for a bugfix soon. I will be happy to provide more details and do testing if needed ...

#80

Posted by aharown07 on April 30, 2009 at 1:38pm

Meanwhile, #53 still works... at least, if you're not doing anything fancy with the format. Haven't tested that.

#81

Posted by gettingpissed on May 1, 2009 at 11:12am

Just upgraded to find that the relative "now" views calendar bug is still here, and this one was added...

Please fix :)

#82

Posted by regi.bradley on May 2, 2009 at 10:54am

+1

#83

Posted by macrocosm on May 3, 2009 at 8:12am

Im using the latest dev and now get this error, again. Guess the fix isn't in the dev yet.
I had applied a patch above that worked but the update killed it.
Now I have to figure out which on one of the patches above worked! lol.

I am seeing the warnings when viewing the content_template edit page for the content_type which has the date field in question. I am also seeing the warnings when viewing a users profile that has the content_type as a piece of their profile (though only if their date field is blank).

warning: date_format() expects parameter 1 to be DateTime, null given.... yada yada..

#84

Posted by macrocosm on May 3, 2009 at 8:14am

Just wanted to add that the bug appears regardless of the Default value: being blank or now.

#85

Posted by macrocosm on May 3, 2009 at 8:31am

Oh well, the patch in #12 from lonelyrobot that fixed it for me last week no longer works with the latest dev version. ....Hunk #1 FAILED at 649.

#86

Posted by mrsimonelliott on May 4, 2009 at 2:50pm

I have the same message as #75 but pages of them
I am using latest 6.dev of date and calendar. I am not using date repeat or any Ical functionality.
In my default calendar view, months view works fine, year view gives all the error messages.
It was all working fine this morning then I updated a date in one of my posts and it all went wrong.

#87

Posted by macrocosm on May 5, 2009 at 10:34pm

For some reason its very unhappy with empty date fields. The worst one for me is a date field i placed in the user profiles, there is no way to change settings ... even still the date field I have in my content profile bit which does have settings is still doing the same thing. Whats strange is that other date fields I have on other content types are behaving fine. So maybe its something to do with user profiels and content profiles?

#88

Posted by David_Rothstein on May 5, 2009 at 10:52pm
Status:postponed (maintainer needs more info)» needs review

It seems like enough people are still experiencing these kinds of errors that we can safely set this back to "needs review".

I think the patch in #53 should fix all of them, since it addresses the problem at its root. But the only way to find out for a particular use case is to test the patch :) Once enough people have tested it, it's fair for someone to mark it "reviewed and tested by the community" (I assume we're pretty close to that already....)

#89

Posted by David_Rothstein on May 5, 2009 at 11:07pm
Status:needs review» needs work

Well, on second thought, the patch no longer applies any more, and hasn't since April 28. The fix that was committed then is essentially identical to the first part of my patch in #53:
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/date/date_a...

So I'm pretty sure the original problem is now fixed.

Unfortunately, it seems like there are now several different bugs all being reported in the same issue.... Not sure what to do about that, since it makes things a bit confusing, but I guess the issue should stay open for now :)

#90

Posted by illskillz on May 7, 2009 at 3:54pm

Thanks David for the link. The code changes fixed the error for me.

#91

Posted by kidrobot on May 8, 2009 at 11:34pm

The problem relating to empty date fields still applies to non-repeating fields.

I'm using Date with the EXIF module ie. I have a datetime field field_ifd0_datetime which gets its value from the image submitted. When this value is not present I get these errors when trying to save the node form.

* warning: date_format() expects parameter 1 to be DateTime, null given in... date.module on line 351.
* warning: date_timezone_set() expects parameter 1 to be DateTime, null given... in date.module on line 353.
* warning: date_format() expects parameter 1 to be DateTime, null given in... date.module on line 355.
* warning: date_offset_get() expects parameter 1 to be DateTime, null given in... date.module on line 357.

I upgraded to 6.2xdev as of May 5
Ran update.php
Cleared caches
Uploaded image with no datetime

#92

Posted by joe.baz on May 11, 2009 at 6:01pm

Hi there,

I was able to reproduce these warning notices after switching on/off the permissions in the following: content_permissions module > view field_date. When turned off, I get the following errors:

warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 414.
warning: date_format() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 416.
warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 414.
warning: date_format() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 416.
warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 414.
warning: date_format() expects parameter 1 to be DateTime, null given in /home/content/e/x/3/ex3mplar/html/drupal/sites/all/modules/calendar/includes/calendar.inc on line 416.

When turned on, the warning errors go away. Hope this helps others!

This assumes the application of patch #53.

#93

Posted by mikesign on May 11, 2009 at 8:42pm

Ok I'm a noob!

I want to use the patch @53 to see if it works, does it apply to Drupal core or just the specific "Date" Module?

I am using a Mac, If i where to use terminal to edit the code where would that be located? The code snippet listed by David in post 89.

Thanks for such a great active forum. Lots to learn!

#94

Posted by aharown07 on May 12, 2009 at 1:37am

The #53 patch applies to Date module only and also only to a particular release... and it may be a dev release. Can't remember now. If you read closely around post #53 and later you can probably find the info there somewhere as to what release it applies to. ....and for some it seemed to not work though I'm not sure they were having exactly the same problem.

Edit: Ok, looks like post #55 indicates the patch applies to the dev release that was then "latest." So you're looking for a dev release dated latest before Apr 15.

#95

Posted by KarenS on May 13, 2009 at 12:54am
Status:needs work» fixed

Did anyone read #89, code similar to what was in the patch in #53 has already been committed, there is nothing to patch. But people have now reported a whole slew of different errors in the same issue, most with too little information to do anything with them, so this issue is totally polluted (and too long anyway).

If there are errors in the very very latest -dev code, try the troubleshooting tips on the Date project page, and if those don't work, start a new issue, carefully explaining what the errors are, exactly how your date field is set up, and how to reproduce the problem. And don't report different errors in the same issue.

#96

Posted by yan on May 13, 2009 at 4:26pm

#89 solved it for me. Is there gonna be a new release with this change soon?

#97

Posted by Levure on May 13, 2009 at 9:33pm

Is a new stable release planned in the near future ?
I'm not allowed to install or to upgrade to any -dev- release :-(

#98

Posted by smokeyd on May 19, 2009 at 10:50am
Version:6.x-2.x-dev» 6.x-2.1

I was having this problem as well with 6.x-2.1 under the same circumstances: Have the repeat module enabled, then create a new content type with a date field, including the repeating fields. Create a new node of that type, but do not enter any data in the repeating area. The same warnings appeared.
Applying the patch form #12 fixed it for me.

#99

Posted by slabcreek on May 29, 2009 at 12:57am

Was getting the same error in my Calendar views - updating to the latest date and calendar devs seems to have fixed it. Thanks!

#100

Posted by System Message on June 12, 2009 at 1:00am
Status:fixed» closed (fixed)

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