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.
Comment | File | Size | Author |
---|---|---|---|
#53 | date_repeat.patch | 2.59 KB | David_Rothstein |
#12 | date-409476.patch | 1.43 KB | lonelyrobot |
#10 | date-409476.patch | 1.64 KB | lonelyrobot |
#8 | date-409476.patch | 811 bytes | lonelyrobot |
Comments
Comment #1
likewhoa CreditAttribution: likewhoa commentedi can't reproduce this on another boxen, closing so i can fix.
Comment #2
prhodes CreditAttribution: prhodes commentedI 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.
Comment #3
prhodes CreditAttribution: prhodes commentedDisabling 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.
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedsame 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.
Comment #5
prhodes CreditAttribution: prhodes commentedAdded 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.
Comment #6
prhodes CreditAttribution: prhodes commentedSorry 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";}
)
Comment #7
prhodes CreditAttribution: prhodes commentedComment #8
lonelyrobot CreditAttribution: lonelyrobot commentedOops.... DON'T USE THIS
Comment #9
arlinsandbulte CreditAttribution: arlinsandbulte commentedSteps I can use to reproduce this issue:
Comment #10
lonelyrobot CreditAttribution: lonelyrobot commentedThis one seems to be working.
Comment #11
srjoshI'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
Comment #12
lonelyrobot CreditAttribution: lonelyrobot commentedRerolled 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).
Comment #13
Bremen Saki CreditAttribution: Bremen Saki commentedI'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.
Comment #14
gorcon CreditAttribution: gorcon commentedSeeing 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.
Comment #15
lonelyrobot CreditAttribution: lonelyrobot commentedChanging the status.
Comment #16
mreyher CreditAttribution: mreyher commentedSame error here... will turning off iCal supress the errors until there is a fix?
Comment #17
lonelyrobot CreditAttribution: lonelyrobot commentedHas anyone tried the patch in comment #12? Does it not work? This has fixed the issue for me.
Comment #18
robbieferrero CreditAttribution: robbieferrero commentedI 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).
Comment #19
tekknogeek CreditAttribution: tekknogeek commentedHello, 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.
Comment #20
Ron Collins CreditAttribution: Ron Collins commented@12
i couldn't apply the patch in the usual way but i did manually applied them which cleans up the error.
thanks.
Comment #21
philsward CreditAttribution: philsward commentedIn response to comment #16, I have not enabled ical at all, and still received the error...
Comment #22
Hoople CreditAttribution: Hoople commentedThanks for the patch. When will date 2.2 be released with this fix in it?
Comment #23
blackdog CreditAttribution: blackdog commentedPatch in #12 works great!
Comment #24
KarenS CreditAttribution: KarenS commentedI'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.
Comment #25
sbayne CreditAttribution: sbayne commentedThe patch in #12 fixed it for me as well.
Comment #26
KarenS CreditAttribution: KarenS commentedUnless 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.
Comment #27
KarenS CreditAttribution: KarenS commentedEr, the question I *asked* in #24.
Comment #28
lonelyrobot CreditAttribution: lonelyrobot commentedif 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:
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
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?
Comment #29
sharrison CreditAttribution: sharrison commentedCould 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.
Comment #30
david.sarnowski CreditAttribution: david.sarnowski commentedI could use some instructions on applying this patch as well!
Thanks
Comment #31
blackdog CreditAttribution: blackdog commented@ #29 & 30: see http://drupal.org/patch/apply
Comment #32
Macronomicus CreditAttribution: Macronomicus commentedfor 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!
Comment #33
mariagwyn CreditAttribution: mariagwyn commentedI can confirm that the patch works, but I can't offer anything on whether it destroys other elements of the date functions.
Comment #34
xmacinfoSame 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. ;-)
Comment #35
giggler CreditAttribution: giggler commentedsubscribing
Comment #36
ShutterFreak CreditAttribution: ShutterFreak commentedSubscribing 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:
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
Comment #37
likewhoa CreditAttribution: likewhoa commentedtake a look at patch on comment #24.
Comment #38
Anonymous (not verified) CreditAttribution: Anonymous commentedsubscribe
Comment #39
amariotti CreditAttribution: amariotti commentedsubscribing...
Comment #40
arosemartin CreditAttribution: arosemartin commentedSubscribing, I have this exact problem..
Comment #41
georgedamonkey CreditAttribution: georgedamonkey commentedsubscribing
Comment #42
jsimonis CreditAttribution: jsimonis commentedIt 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?
Comment #43
cletusalphonse CreditAttribution: cletusalphonse commentedSubscribing, same issue here.
Comment #44
snorkers CreditAttribution: snorkers commentedIs 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...
Comment #45
pippal CreditAttribution: pippal commented#19 patch works with 5.x-2.6
Comment #46
xmacinfoTo 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.
Comment #47
jerror.me CreditAttribution: jerror.me commentedPossible 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!
Comment #48
j_ten_man CreditAttribution: j_ten_man commentedsubscribe
Comment #49
xmacinfoCorrect bug tracking info.
Comment #50
alphex CreditAttribution: alphex commentedsubscribe.
would be nice to see this in a official release to solve whats kinda a big issue ...
thanks.
Comment #51
gpk CreditAttribution: gpk commentedChanging 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.
Comment #52
dvc9 CreditAttribution: dvc9 commentedsubscribing...
Comment #53
David_Rothstein CreditAttribution: David_Rothstein commentedI 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 indate_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.Comment #54
xmacinfoQuestions 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. ;-)
Comment #55
David_Rothstein CreditAttribution: David_Rothstein commentedYup, 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 :)
Comment #56
Levure CreditAttribution: Levure commentedsubscribing...
Comment #57
chey CreditAttribution: chey commentedThe 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
Comment #58
GregoryHeller CreditAttribution: GregoryHeller commented@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)
Comment #59
jfeiler CreditAttribution: jfeiler commentedI'm seeing it consistently on unlogged-in users but not authenticated users--anyone else?
Comment #60
aharown07 CreditAttribution: aharown07 commentedsubscribing
Comment #61
techtweaker CreditAttribution: techtweaker commentedHow do I "subscribe" to an issue, to follow up on it. Is commenting enough?
Comment #62
Colorful Tones CreditAttribution: Colorful Tones commentedsubscribing
Comment #63
snorkers CreditAttribution: snorkers commented@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.
Comment #64
aharown07 CreditAttribution: aharown07 commented@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.
Comment #65
glass.dimly CreditAttribution: glass.dimly commentedWhew. All that said... +1.
Comment #66
greggdickson CreditAttribution: greggdickson commented+1
Comment #67
becca08 CreditAttribution: becca08 commentedanother +1
Comment #68
aharown07 CreditAttribution: aharown07 commented@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.
Comment #69
David_Rothstein CreditAttribution: David_Rothstein commented@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 :)
Comment #70
aharown07 CreditAttribution: aharown07 commentedWill definitely give it a whirl & report shortly.
Edit... having trouble running the patch against 6x-2.1
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.
Comment #71
aharown07 CreditAttribution: aharown07 commentedPatch 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.
Comment #72
zeropaper CreditAttribution: zeropaper commented#53 worked for me
Comment #73
KarenS CreditAttribution: KarenS commentedI 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.
Comment #74
fox 2 CreditAttribution: fox 2 commentedI 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.
Comment #75
fox 2 CreditAttribution: fox 2 commentedthe 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.
Comment #76
fox 2 CreditAttribution: fox 2 commentedok 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 :)
Comment #77
reaneyk CreditAttribution: reaneyk commentedsubscribing
Comment #78
11thfinger CreditAttribution: 11thfinger commentedI'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.
Comment #79
profix898 CreditAttribution: profix898 commentedI 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 ...
Comment #80
aharown07 CreditAttribution: aharown07 commentedMeanwhile, #53 still works... at least, if you're not doing anything fancy with the format. Haven't tested that.
Comment #81
J V CreditAttribution: J V commentedJust upgraded to find that the relative "now" views calendar bug is still here, and this one was added...
Please fix :)
Comment #82
regi.bradley CreditAttribution: regi.bradley commented+1
Comment #83
Macronomicus CreditAttribution: Macronomicus commentedIm 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..
Comment #84
Macronomicus CreditAttribution: Macronomicus commentedJust wanted to add that the bug appears regardless of the Default value: being blank or now.
Comment #85
Macronomicus CreditAttribution: Macronomicus commentedOh 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.
Comment #86
mrsimonelliott CreditAttribution: mrsimonelliott commentedI 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.
Comment #87
Macronomicus CreditAttribution: Macronomicus commentedFor 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?
Comment #88
David_Rothstein CreditAttribution: David_Rothstein commentedIt 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....)
Comment #89
David_Rothstein CreditAttribution: David_Rothstein commentedWell, 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 :)
Comment #90
illskillz CreditAttribution: illskillz commentedThanks David for the link. The code changes fixed the error for me.
Comment #91
hitfactory CreditAttribution: hitfactory commentedThe 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
Comment #92
joe.baz CreditAttribution: joe.baz commentedHi 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.
Comment #93
mikesign CreditAttribution: mikesign commentedOk 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!
Comment #94
aharown07 CreditAttribution: aharown07 commentedThe #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.
Comment #95
KarenS CreditAttribution: KarenS commentedDid 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.
Comment #96
yan CreditAttribution: yan commented#89 solved it for me. Is there gonna be a new release with this change soon?
Comment #97
Levure CreditAttribution: Levure commentedIs a new stable release planned in the near future ?
I'm not allowed to install or to upgrade to any -dev- release :-(
Comment #98
DolfAndringa CreditAttribution: DolfAndringa commentedI 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.
Comment #99
slabcreek CreditAttribution: slabcreek commentedWas getting the same error in my Calendar views - updating to the latest date and calendar devs seems to have fixed it. Thanks!