timezone_open() and date_timezone_set() warnings on archive default view

The error lives in views_handler_argument_dates_various.inc

Everywhere format_date() is called, we are passing it 0 when it expects NULL (the function does an isset() check). I can resolve the issue by modifying the code on lines 22, 29, 66, 73, 104, 133 and 141.

For instance, instead of
return format_date(strtotime($created), 'custom', $this->format, 0);
We need
return format_date(strtotime($created), 'custom', $this->format, NULL);

Sorry I'm not a cool CVS patcher dude. :P

Please provide a real patch. So it's easier for other people to test the patch.

Okay, so I've just given myself a quick crash course in CVS and here is my first patch. Can someone tell me if I've done it correctly?

Doesn't apply.

The patch needs to be made from the root directory, so that I can do this:

cd views/
patch -p0 < views.patch

I suggest using cvs or git to roll the patch (make the changes in a CVS checkout, then "cvs diff -up > views.patch", for example).

Other than that, the code changes are RTBC. Did a grep, those are the only places still left with the D6 syntax.

Disclaimer: i'm not online :(

So what does the d6 code of format_date

  if (!isset($timezone)) {
    global $user;
    if (variable_get('configurable_timezones', 1) && $user->uid && strlen($user->timezone)) {
      $timezone = $user->timezone;
    }
    else {
      $timezone = variable_get('date_default_timezone', 0);
    }
  }

  $timestamp += $timezone;

So here it adds nothing to the timestamp in the current code.

What does d7:

$timezone Time zone identifier; if omitted, the user's time zone is used.

There is a difference between adding 0 and using the user's time zone from my perspective

@bojanz
Sorry, I have no idea how to do that. I am using TortoiseCVS on Windows.

@dereine
The original error was caused by using 0 as a timezone (hence Unknown or bad timezone (0)). By setting it to NULL (the default value) it will run through and get the user's timezone.

@Chris Gillis

I understand that this does not report an error. But the question is does the code the same as in d6?

In any case, the patch is consistent with how format_date is used elsewhere in D7 Views (we don't pass the timezone anywhere). It's debatable whether this is correct, but it's at least consistent.

Shouldn't this be the php server time zone? This might change from UTC

Thanks. Commited.

I still encounter this error. Views 7.x-3.3.

Contextual Filter: Created year + month

When you are returning 'all' it will result an error

Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1909 of /root/includes/common.inc).

Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1919 of /root/includes/common.inc).

I'm experiencing the same as #16. Patch attached.

I applied #17 but still get the error when using 'all' argument (the view still works fine, displaying all results).

Warning: date_timezone_set() expects parameter 1 to be DateTime, boolean given in format_date() (line 1937 of mysite/drupal7/includes/common.inc).
Warning: date_format() expects parameter 1 to be DateTime, boolean given in format_date() (line 1947 of mysite/drupal7/includes/common.inc).

+++ b/modules/node/views_handler_argument_dates_various.incundefined
@@ -33,7 +33,10 @@ class views_handler_argument_node_created_fulldate extends views_handler_argumen
+    $timestamp = strtotime($this->argument . "15" . " 00:00:00 UTC");

The 15 definitive needs some explanation.

Additional the patch seems to produce some problems, so needs work.

Wow, I have no idea why I have that . "15" in there :(
That is bizarre.

The 15 came from the views_handler_argument_node_created_year_month title() function that does not have a day component :)

I managed to have this triggered in another handler today too, so this includes preemptive strike of the notice on all title() calls in the file.

Ah. Today's error was using "Created year + month", the first patch was for the more generic "Created date - CCYYMMDD"

One way to deal with this (in d7) is to set your exception value to a recognisable format.

For instance for a "created year + month" contextual filter I asked it to look for '000000' instead of 'all', worked a treat.

Does this need to be bumped to D8 core before backporting; is it even an issue there?

I also encountered this issue when the date argument was some invalid value (like "0.85"). This patched fixed the issue for me. Thanks!

Confirmed via the strtotime() documentation that this is the correct way of handling it.

Committed.

This probably affects D8 but I haven't tried to replicate if the code is exposed.

i.e. same code in Drupal\views\Plugin\views\argument\Date::summaryName() and Date::title()

If so, create a new core issue referencing this thread :)

Edit: Date was the parent class to the 4 classes, which I assumed contained the abstract signatures for those 4 sub-classes, but it doesn't (as noted below)

Yeah, I don't see an issue that contains "strtotime" and is related to this problem.

FYI similar code is in:

• core/modules/views/src/Plugin/views/argument/DayDate.php
• core/modules/views/src/Plugin/views/argument/FullDate.php
• core/modules/views/src/Plugin/views/argument/MonthDate.php
• core/modules/views/src/Plugin/views/argument/YearMonthDate.php