date_timezone_set() expects parameter 1 to be DateTime, null given

Changing the title to be more descriptive. Thanks for trying the checklist first, I know I can rule those things out.

Now I need more information about this specific problem like what were you doing when you saw the message, how is your date field configured (what kind of field, what kind of widget, what timezone and granularity settings), and how is your view configured (you can paste an export of the view here, wrap it in <code></code>).

Also, if this doesn't happen for user #1, is there data in the view that is protected and not visible to others? If so I need some idea of how permissions are set up. For instance, is this a field that you have set permissions on using Content Permissions, or are they nodes that some roles are not allowed to view in one of the node access modules?

I'm having the same issue. Just updated from 6.8 to 6.11 drupal. Using latest non-dev calendar module, and latest views/date modules.
MY datefield shows the following:
Date: Date Content: Event Date and Time (field_event_datetime) - From date

I did a search on Google, this error is ALL OVER THE PLACE! Many sites are getting this exact same error!

MY exported view:
$view = new view; $view->name = 'Church_Calendar'; $view->description = 'Calendar of church events'; $view->tag = 'Calendar'; $view->view_php = ''; $view->base_table = 'node'; $view->is_cacheable = FALSE; $view->api_version = 2; $view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */ $handler = $view->new_display('default', 'Defaults', 'default'); $handler->override_option('fields', array( 'title' => array( 'label' => '', 'alter' => array( 'alter_text' => 0, 'text' => '', 'make_link' => 0, 'path' => '', 'alt' => '', 'prefix' => '', 'suffix' => '', 'help' => '', 'trim' => 0, 'max_length' => '', 'word_boundary' => 1, 'ellipsis' => 1, 'strip_tags' => 0, 'html' => 0, ), 'link_to_node' => 1, 'exclude' => 0, 'id' => 'title', 'field' => 'title', 'table' => 'node', 'relationship' => 'none', ), )); $handler->override_option('sorts', array( 'field_event_datetime_value' => array( 'order' => 'ASC', 'delta' => -1, 'id' => 'field_event_datetime_value', 'table' => 'node_data_field_event_datetime', 'field' => 'field_event_datetime_value', 'relationship' => 'none', ), )); $handler->override_option('arguments', array( 'date_argument' => array( 'default_action' => 'default', 'style_plugin' => 'default_summary', 'style_options' => array(), 'wildcard' => 'all', 'wildcard_substitution' => 'All', 'title' => '', 'default_argument_type' => 'date', 'default_argument' => '', 'validate_type' => 'none', 'validate_fail' => 'not found', 'date_fields' => array( 'node_data_field_event_datetime.field_event_datetime_value' => 'node_data_field_event_datetime.field_event_datetime_value', ), 'year_range' => '-3:+3', 'date_method' => 'OR', 'granularity' => 'month', 'id' => 'date_argument', 'table' => 'node', 'field' => 'date_argument', 'relationship' => 'none', 'default_argument_user' => 0, 'default_argument_fixed' => '', 'default_argument_php' => '', 'validate_argument_node_type' => array( 'poll' => 0, 'forum' => 0, 'event' => 0, 'page' => 0, 'profile' => 0, 'story' => 0, ), 'validate_argument_node_access' => 0, 'validate_argument_nid_type' => 'nid', 'validate_argument_vocabulary' => array( '1' => 0, ), 'validate_argument_type' => 'tid', 'validate_argument_php' => '', 'override' => array( 'button' => 'Override', ), 'default_options_div_prefix' => '', 'validate_user_argument_type' => 'uid', 'validate_user_roles' => array( '2' => 0, '3' => 0, '5' => 0, '4' => 0, ), 'validate_argument_transform' => 0, 'validate_user_restrict_roles' => 0, ), )); $handler->override_option('filters', array( 'status' => array( 'operator' => '=', 'value' => 1, 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'id' => 'status', 'table' => 'node', 'field' => 'status', 'relationship' => 'none', ), 'type' => array( 'operator' => 'in', 'value' => array( 'event' => 'event', ), 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'id' => 'type', 'table' => 'node', 'field' => 'type', 'relationship' => 'none', ), )); $handler->override_option('access', array( 'type' => 'none', 'role' => array(), 'perm' => '', )); $handler->override_option('title', 'Calendar'); $handler->override_option('items_per_page', 0); $handler->override_option('use_more', 0); $handler->override_option('style_plugin', 'calendar_nav'); $handler = $view->new_display('calendar', 'Calendar page', 'calendar_1'); $handler->override_option('path', 'calendar'); $handler->override_option('menu', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, 'name' => 'navigation', )); $handler->override_option('tab_options', array( 'type' => 'none', 'title' => '', 'description' => '', 'weight' => 0, )); $handler->override_option('calendar_colors', array( 'page' => '#ffff66', 'story' => '#668cff', )); $handler->override_option('calendar_colors_vocabulary', array()); $handler->override_option('calendar_colors_taxonomy', array()); $handler->override_option('calendar_popup', 0); $handler->override_option('calendar_date_link', ''); $handler = $view->new_display('calendar_block', 'Calendar block', 'calendar_block_1'); $handler->override_option('block_description', 'Calendar'); $handler->override_option('block_caching', -1); $handler = $view->new_display('calendar_period', 'Year view', 'calendar_period_1'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'year', 'name_size' => '1', 'max_items' => '0', 'truncated_fields' => array(), 'truncate_length' => '', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'year'); $handler = $view->new_display('calendar_period', 'Month view', 'calendar_period_2'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'month', 'name_size' => '99', 'with_weekno' => '1', 'date_fields' => NULL, 'max_items' => '3', 'truncated_fields' => array( 'node_title' => 'node_title', ), 'truncate_length' => '12', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'month'); $handler = $view->new_display('calendar_period', 'Day view', 'calendar_period_3'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'name_size' => '99', 'with_weekno' => 0, 'max_items' => 0, 'max_items_behavior' => 'more', 'groupby_times' => 'hour', 'groupby_times_custom' => '', 'groupby_field' => '', 'truncated_fields' => array(), 'truncate_length' => '20', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'day'); $handler = $view->new_display('calendar_period', 'Week view', 'calendar_period_4'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'name_size' => '99', 'with_weekno' => 0, 'max_items' => '0', 'max_items_behavior' => 'more', 'groupby_times' => 'hour', 'groupby_times_custom' => '', 'groupby_field' => '', 'truncated_fields' => array(), 'truncate_length' => '20', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 'calendar_1', 'default' => 0, 'calendar_block_1' => 0, )); $handler->override_option('calendar_type', 'week'); $handler = $view->new_display('calendar_period', 'Block view', 'calendar_period_5'); $handler->override_option('style_plugin', 'calendar_style'); $handler->override_option('style_options', array( 'display_type' => 'month', 'name_size' => '1', )); $handler->override_option('attachment_position', 'after'); $handler->override_option('inherit_arguments', TRUE); $handler->override_option('inherit_exposed_filters', TRUE); $handler->override_option('displays', array( 'calendar_1' => 0, 'default' => 0, 'calendar_block_1' => 'calendar_block_1', )); $handler->override_option('calendar_type', 'month'); $handler = $view->new_display('block', 'Upcoming', 'block_1'); $handler->override_option('arguments', array()); $handler->override_option('filters', array( 'status' => array( 'operator' => '=', 'value' => 1, 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'id' => 'status', 'table' => 'node', 'field' => 'status', 'relationship' => 'none', ), 'type' => array( 'operator' => 'in', 'value' => array( 'page' => 'page', 'story' => 'story', ), 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => FALSE, 'label' => '', ), 'id' => 'type', 'table' => 'node', 'field' => 'type', 'relationship' => 'none', ), 'date_filter' => array( 'operator' => '>=', 'value' => array( 'value' => NULL, 'min' => NULL, 'max' => NULL, 'default_date' => 'now', 'default_to_date' => '', ), 'group' => '0', 'exposed' => FALSE, 'expose' => array( 'operator' => 'date_filter_op', 'label' => 'Date:', 'use_operator' => 1, 'identifier' => 'date_filter', 'optional' => 1, 'remember' => 0, ), 'date_fields' => array( 'node.changed_value' => 'node.changed_value', ), 'granularity' => 'day', 'form_type' => 'date_select', 'default_date' => 'now', 'default_to_date' => '', 'id' => 'date_filter', 'table' => 'node', 'field' => 'date_filter', 'override' => array( 'button' => 'Use default', ), 'relationship' => 'none', ), )); $handler->override_option('items_per_page', 5); $handler->override_option('use_more', 1); $handler->override_option('style_plugin', 'list'); $handler->override_option('style_options', array( 'grouping' => '', 'type' => 'ul', )); $handler->override_option('block_description', 'Upcoming'); $handler->override_option('block_caching', -1);

Thanks for any assistance. The calendar is working, even popup, but this error message on top of page as per initial poster. This happens for ALL users.

Layoric

I also found that the events are showing times/dates in a strange format when I click on an event in calendar. Time is in 24hr format, and dates are backwards, showing year first, then month, then day.

I'm having almost the exact same problem. I have it repeating all the way down the page, I'm assuming from multiple calendar entries.

It's giving me these two:
warning: date_timezone_set() expects parameter 1 to be DateTime, null given in /sites/all/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 /sites/all/modules/calendar-6.x-2.1/calendar/includes/calendar.inc on line 416.

but, repeating it down the page sixteen times. I'm running out of ideas on how to fix this. It's not inhibiting users from viewing things on the calendar, but pops in upon authenticated user login and refuses to go away. Out of all the bugs I fixed, this is the only one I can't crack. I have a patch from another post waiting in the wing, but I'm not sure if it's going to actually work or not.

Would this have something to do with CCK? I haven't made any CCK fields yet, but all CCK and Date/time options are activated.

Thanks in advance.

Just Upgraded from 6.10 to 6.11 and I am getting the same error message?
warning: date_timezone_set() expects paramete....

Anyone have any idea yet about how to fix this?

Thinking about switching back to 6.10 to see if that will help.
Just a thought You have to deselect all of the added modules to upgrade then add them back in and run the update.php. I'm wondering if there is something that defaulted back to an original setting?

Thanks to all that are trying to fix this! I'm not that smart :-)
Mike

I've just had the same problem but seemed to have fixed it, but I'm not totally sure how. I know this is a bit vague but there might just be something that will help here.
I have just upgraded many modules all at once, including Drupal 6.9 to 6.11, Calendar 6.x-2.x-dev (Jan 24th) to 2.1, date 2-rc6 to 2.1 and views 2.2 - 2.5. I was getting the same error as this post started with, other than that it was in calendar.inc lines 401 and 416. I did all items in Karen's checklist but still present. The interesting thing was that it only occurred in year view, not day or month view, and I checked every month in the year in month view. The year view used default settings rather than overrides for fields and arguments so nothing there that helped. Although I use a theme with lots of custom theming for the calendar display, the problem occurred in Minnelli as well. I traced it down to a particular one of the 3 content types I'm displaying, which all include a date range. If I removed this content type (Timetable start date) from fields or I removed it from the check list under 'Arguments Date:Date (node)', then problem went away. I'd gone to the content type, manage fields and changed various things, re-saved etc, no help. I didn't want to re-create that content type as it has a huge amount of data in it. so it was only a combination of this one particular content type (very similar to the other 2 types used) and year view that caused a problem. My final step from Karen's check list was to install latest dev code for Date and Calendar, clear the caches and try again - no help. Then something fixed it. The specific thing I did (and about the only thing as best I can remember) was to once again remove this content type from the check list within 'Arguments Date:Date (node)', update, then put it back again. It all then started working. So I guess the message here is that if you've tried all the steps in Karen's check list with latest official release, then you need to try them all again with the latest dev.

Two things that may not be relevant at all but worth mentioning:
1) When I go into the 'manage fields' for my content type and go down to 'default display' drop down selector, there are multiple entries for a number of the values. There are 4 identical and adjacent entries for 'date range', 'Event start date', 'Facilities start date' and 'Timetable start'. It is the 'Timetable start' that has been causing the above problem, it is the last in the list and sometimes it only has 3 entries in the list, not 4.

2) The other (probably unrelated) thing which I think would be useful to have in Karen's check list is to clear out all date and calendar code when upgrading (probably views as well) as it can cause a White Screen of Death (WSOD) on upgrading.

OK - I've made a mistake in reporting what I've done in #9 - the problem is still there. When I re-added Content: Timetable start (field_tt_start) - From date to the check list within 'Arguments Date:Date (node)', it was actually the field 'To date' I'd put back in to try, instead of the 'From date', and that sort of got it working. There is still a problem with my year display not showing the correct timetable information, whereas the month does. I am looking into this further as it uses a lot of custom theming. The year display also is taking many seconds to load on the test server, but not producing any errors on screen or in the watchdog.

As a further test (and perhaps invalid), I changed 'Fields' to use the timetable 'To date' content, rather than the timetable 'From date' content, and this brought the exact same error back again on year display, but month still fine. This is with 'Arguments Date:Date (node)' still having the 'To date' not the 'From date'. It's worth noting that the error message is still showing the problem as being on lines 401 and 416 of calendar.inc, which is different to the original post, and this is using latest dev (date - May 6, Calendar - Apr 29).

This problem is there for user #1 or anonymous user. Investigation continues.

As a further update, currently everything is working for me, whilst using Content: Timetable start (field_tt_start) - To date in the check list within 'Arguments: Date:Date (node)'. i.e. I'm using the 'To' date rather than the 'From' date. My other 2 content types in here still use the 'From' date. Having changed a setting in Views and something in my custom theming, to account for changes in calendar and/or date since before I upgraded (this was a big jump in versions), all my calendar system is now working again. The only mystery is why I have to use the 'To' date rather than the 'From' date, to get this to work.

I’m quite new to Drupal, and am using Acquia Drupal to set up an experimental site for a client. I installed it using SVN, activated most but not all of the optional modules that came with Acquia, installed and customized the Pixture_Reloaded theme, etc.

When I saw the notice of the 6.11 update, I did an “svn up” and everything seemed to be fine. I had previously manually updated Date and a few other Modules, placing them in the overrides directories (/sites/all/modules), and removed them from there after the update (except Date, which appeared not to have been changed by the svn update). But, I had always been logged in as user/1 and had only set up one other user, for the client.

I was just about to call said client when my boss informed me about the error messages that he saw when I asked him to look at the site. He, of course, was unauthenticated. Good thing I didn’t show the client this while those were showing!

It’s not just the warning messages, though. To demonstrate the Calendar Views functionality, I had entered one of their repeating dates (took me a while to figure out how to do that, as it requires that a To date be specified and that makes little conceptual sense for an indefinitely repeating Date, but that’s another subject). When a non-authenticated user (or, presumably, any user other than user/1 according to these messages, but I’ve not yet tried it with others) logs in, the Upcoming View’s list of entries show no dates — just the names of the events! But the dates show up fine for user/1! This is an item of info I have not seen mentioned here, and I wonder if it helps you solve this?

The site is: http://drupal.kreweofgemini.com/

By the way, a Google search on this warning message text (including the specific line numbers) returns hundreds of hits, mostly from Drupal sites that are now showing these warning messages to the world! These include some pretty major sites! I think this issue should be rated “critical,” since it is so publicly visible, and is not just warning messages (e.g. the vanishing of dates from Upcoming View).

Since 6.11 included a critical security fix, going back to 6.10 should probably not be an option.

Temporary Workaround for Warning Messages Issue Only:

In “/admin/settings/error-reporting”, set “Error Reporting:” to “Write errors to the log” instead of “Write errors to the log and to the screen.” This will at least keep users from seeing the warning messages, but does not solve the missing dates in Upcoming Views, nor other side effects. Of course, only do this on the production site, or when showing a development site to the client, otherwise you may miss important error messages that you may need to see. And while in this mode, check the error log often!

P.S. What is this “Karen’s checklist” I keep seeing references to in this thread and others, and where can I find it?

Checklist is under 'Troubleshooting' at http://drupal.org/project/calendar and http://drupal.org/project/date

In #3 I said:

how is your date field configured (what kind of field, what kind of widget, what timezone and granularity settings),

We are now down to #14 and not a single report has yet told me what kind of date fields you are using and how they are configured. That is critical information for me to be able to replicate the problem. Repeating over and over that this is broken is not helpful. I cannot replicate the problem so I need to know how to do it. Telling me how many error messages you see does not help me replicate the problem. Telling me how many times you can find the error messages on Google does not tell me how to replicate the problem. Telling me over and over that this is a critical problem does not help me replicate the problem.

Also, if you are having problems and you followed the trouble-shooting steps, you should be using 6.x-2.x-dev by now (the latest version). If you are using an earlier version, your report won't do anyone any good. If the problem is fixed in the latest version, we're done. If it's not, I need to know what is happening in that version.

@Tony, your report is the most complete, except I don't know how your field is set up. Can you export your content type using Content Copy? That will show me exactly what is in your field configuration. And it would also help to know some of the actual dates that are in your database for the time period you are trying to view.

One thing I can tell from the above messages is that there are some date values that ought to be there but aren't which is why it is so critical to know how the field is configured and what data is in it so I can try to create something similar.

@Karen,
Attached are various files hopefully giving you what you've asked for, with some other things that might be useful. As the problem only occurs in year view, Ican only provide you with 'All the dates' for the year, so it's a lot.
The files are:
tt_service_content_type.txt - This is the content type casuing the problem, it requires the 'To' date in args, not 'From' date'
facilities_content_type.txt - This is a similar content type that is OK (used in the view)
event_content_type.txt - This is another similar content type that is OK (used in the view)
view_working_using_to_date.txt - The exported view using the tt_service 'To' date - so this works
view_notworking_using_from_date.txt - The exported view using the 'From' date - causes 204 pairs of errors in year view only. Live 186 is the only difference.
tt_service dates.txt - dates for each of the different content created with content type 'tt_service'. Event and facility dates can be supplied but they work anyway. they both contain both single dates and date ranges.

One thing I tried was removing dates that spanned over the year ends - no different.

I found Tony's issue, the only one that provided enough info for me to do anything. It was caused by empty date fields in the calendar, which in turn was because there was more than one date field in the view, the only time the query would be returning empty values.

I have no idea if it will fix everyone else's problem but I can't tell if everyone is reporting the same problem, and if so, whether they are using the latest -dev version of the code and whether they followed the trouble-shooting steps to clear the caches. So I'm marking this issue fixed because it's way too polluted to do anything more with.

The fix is going into cvs now. It won't show up in the tarball until the tarball is updated (might be tomorrow).

After that if there are further problems open a new issue after making sure you have the latest version and have followed all the trouble shooting steps, and provide the kind of detail that tony did with exports of your fields and your view so that I can replicate the problem.

Karen, like I said, I’m new here, and weren’t understanding what you meant.

My Events Calendar only has one entry in it so far, but it’s a repeating entry, set to every 2^nd Thursday @ 5:30pm until Dec. 31, 2011. Does that help?

I added some custom fields to the Events node type, but none of them are Date fields.

Oops, was unfamiliar with the Forum software and didn’t mean to change the status. This post is to change it back.

Also: I am using 6.x-2.1, which is the latest version shown by Home » Administer » Reports » Available Updates. Where would I get the dev versions? Dev versions of other modules are shown as available in this report, even if not the recommended version.

The dev versions show up as links on the project pages, http://drupal.org/project/date and http://drupal.org/project/calendar. The trouble-shooting instructions are there, too, so you should read through those. When you're trying to fix a bug, you sometimes need to get the -dev version, even though it isn't the recommended version, because that's where the bugfixes are.

OK, good. Thanks!

Working for me! Thanks for your help and all the work you put in on these modules.
Tony

The error message problem is solved for me as well (I re-enabled “Write errors to the log and to the screen”), but even after re-saving Views and Events, I’m still getting the no dates showing for unauthenticated users in Upcoming View, and a new problem is happening as well. I’ll start new issues about these.

Note: I had to remove the old installation of Calendar 6.x-2.1 (in Modules/Acquia/Calendar) entirely (actually moved it to a directory outside of Drupal) after installing the new one in Sites/All/Modules/Calendar, or else I got a fatal PHP error message about a duplicate definition. Unfortunately, I forgot to copy it. But removing the old module from its former place solved that problem.

The brand new issue that has cropped up with this version is documented in #460776: Repeating Date Rule Display missing Ordinal word (e.g. “Second”) when displayed in View, e.g. Upcoming.

(delete — accidental duplicate post)

I see same error but on different line:

date_format() expects parameter 1 to be DateTime, null given in .../sites/all/modules/calendar/theme/theme.inc on line 16.

I have the same error, and I think I know the reason. Quite obvious, imo.

[calendar module dir]/includes/calendar.inc, function calendar_build_nodes(), line 411

<?php    
        // End date
        $date = date_make_date($values[1], $db_tz, $field['sql_type']);
        if ($db_tz != $to_zone) {
          date_timezone_set($date, timezone_open($to_zone));
        }
?>

Now what if $values[1] is NULL ?
Which happens if an event's end date is not set.

I don't see yet how it is relevant for this to be logged in as the admin user, but the problem itself is quite obvious.
If my error is the same as yours.

Error messages:

warning: date_timezone_set() expects parameter 1 to be DateTime, null given in [calendar module dir]/includes/calendar.inc on line 414.
warning: date_timezone_set() expects parameter 1 to be DateTime, null given in [calendar module dir]/includes/calendar.inc on line 416.

and btw, it's a Datestamp field type that I use, imported from a google calendar iCal feed.
Maybe I should use Date instead?

It seems that the $items parameter for calendar_build_nodes has no end time, unless you are logged in as admin.

Upgrade to 2.2 fixed the issue for me. Thank you, and sorry for the noise.

I have 2.2, but have this error. Based on donquixote's comment, added if link around.

What's the status here?!

edit

Patch on #34 does nothing at all. Entering some non-existent data in a view that uses Date / Calendar still throws the error.

The error is thrown from theme.inc on lines 15-16. You could add a check for the end and start date like:

  $vars['min_date_formatted'] = $view->date_info->min_date ? date_format($view->date_info->min_date, DATE_FORMAT_DATETIME) : '';
  $vars['max_date_formatted'] = $view->date_info->end_date ? date_format($view->date_info->max_date, DATE_FORMAT_DATETIME) : '';

That gets rid of the error, but like before, just because we enter some nasty data into the View, doesn't mean that the calendar should disappear.

The problem is: why aren't the min and end dates provided regardless?????

Patch for comment 39 - still think this needs additional work/investigation

Better patch - fixed paths

Patch in #42 worked for me, solving this problem (note I applied it against Aug 23 dev version of calendar module).

I'm also confirming that #42 worked.

OK, fixed finally. Thanks!