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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

likewhoa’s picture

Status: Active » Closed (fixed)

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

prhodes’s picture

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.

prhodes’s picture

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.

Anonymous’s picture

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.

prhodes’s picture

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.

prhodes’s picture

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";}
)

prhodes’s picture

lonelyrobot’s picture

FileSize
811 bytes

Oops.... DON'T USE THIS

arlinsandbulte’s picture

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.
lonelyrobot’s picture

FileSize
1.64 KB

This one seems to be working.

srjosh’s picture

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

lonelyrobot’s picture

FileSize
1.43 KB

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).

Bremen Saki’s picture

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.

gorcon’s picture

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.

lonelyrobot’s picture

Status: Active » Needs review

Changing the status.

mreyher’s picture

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

lonelyrobot’s picture

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

robbieferrero’s picture

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).

tekknogeek’s picture

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.

Ron Collins’s picture

@12

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

thanks.

philsward’s picture

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

Hoople’s picture

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

blackdog’s picture

Priority: Normal » Critical
Status: Needs review » Reviewed & tested by the community

Patch in #12 works great!

KarenS’s picture

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.

sbayne’s picture

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

KarenS’s picture

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.

KarenS’s picture

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

lonelyrobot’s picture

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?

sharrison’s picture

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.

david.sarnowski’s picture

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

Thanks

blackdog’s picture

Macronomicus’s picture

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!

mariagwyn’s picture

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

xmacinfo’s picture

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. ;-)

giggler’s picture

subscribing

ShutterFreak’s picture

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

likewhoa’s picture

take a look at patch on comment #24.

Anonymous’s picture

subscribe

amariotti’s picture

subscribing...

arosemartin’s picture

Subscribing, I have this exact problem..

georgedamonkey’s picture

subscribing

jsimonis’s picture

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?

cletusalphonse’s picture

Subscribing, same issue here.

snorkers’s picture

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...

pippal’s picture

Version: 6.x-2.1 » 5.x-2.6

#19 patch works with 5.x-2.6

xmacinfo’s picture

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.

jerror.me’s picture

Component: Code » Documentation
Category: bug » 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!

j_ten_man’s picture

subscribe

xmacinfo’s picture

Component: Documentation » Code
Category: task » bug
Priority: Normal » Critical
Status: Needs review » Needs work

Correct bug tracking info.

alphex’s picture

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

gpk’s picture

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.

dvc9’s picture

subscribing...

David_Rothstein’s picture

FileSize
2.59 KB

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.

xmacinfo’s picture

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. ;-)

David_Rothstein’s picture

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 :)

Levure’s picture

subscribing...

chey’s picture

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

GregoryHeller’s picture

@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)

jfeiler’s picture

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

aharown07’s picture

subscribing

techtweaker’s picture

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

Colorful Tones’s picture

subscribing

snorkers’s picture

@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.

aharown07’s picture

@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.

glass.dimly’s picture

Whew. All that said... +1.

greggdickson’s picture

+1

becca08’s picture

another +1

aharown07’s picture

@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.

David_Rothstein’s picture

@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 :)

aharown07’s picture

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.

aharown07’s picture

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.

zeropaper’s picture

#53 worked for me

KarenS’s picture

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.

fox 2’s picture

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.

fox 2’s picture

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.

fox 2’s picture

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 :)

reaneyk’s picture

subscribing

11thfinger’s picture

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.

profix898’s picture

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 ...

aharown07’s picture

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

J V’s picture

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

Please fix :)

regi.bradley’s picture

+1

Macronomicus’s picture

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..

Macronomicus’s picture

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

Macronomicus’s picture

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.

mrsimonelliott’s picture

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.

Macronomicus’s picture

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?

David_Rothstein’s picture

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....)

David_Rothstein’s picture

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 :)

illskillz’s picture

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

hitfactory’s picture

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

joe.baz’s picture

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.

mikesign’s picture

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!

aharown07’s picture

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.

KarenS’s picture

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.

yan’s picture

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

Levure’s picture

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

DolfAndringa’s picture

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.

slabcreek’s picture

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

Status: Fixed » Closed (fixed)

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