Checked out of CVS today (June 9th 2009). Running on Windows, Apache 2.2.x, MySQL database 5.1.34, and PHP 5.2.9-2.

warning: date_timezone_set() expects parameter 2 to be DateTimeZone, string given in C:\Drupal\drupal\sites\all\modules\feedapi_mapper\mappers\feedapi_mapper_date.inc on line 141.

I fixed it by replacing line #141 in mappers/feedapi_mapper_date.inc:
date_timezone_set($value, $to_tz);
With:

  $tz_object = new DateTimeZone($to_tz);
  date_timezone_set($value, $tz_object);
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

Status: Needs work » Closed (duplicate)

This seems to be fixed now - duplicate of ? #504852-4: Warning in feedapi_mapper_date.inc

halstead’s picture

Status: Closed (duplicate) » Needs review
FileSize
915 bytes

I think this is a different issue because it is still present, it's on a different line, and the error message is a bit different. Here is the error with the newest 6.x-1.x:

warning: date_timezone_set() expects parameter 2 to be DateTimeZone, string given in C:\Users\MichaelH\workspace\Sites\acquia-drupal\drupal\sites\all\modules\feedapi_mapper\mappers\feedapi_mapper_date.inc on line 142.

The patch that removed the error for me is attached.

alex_b’s picture

#2 - thank you. Good catch. Can you explain what your patch fixes?

halstead’s picture

Right now a string such as 'Europe/London' is being passed to the function which is expecting a DateTimeZone object so a warning is triggered. I'm creating a DateTimeZone object from the string and passing that instead. This removes the warning.

http://us.php.net/manual/en/datetime.settimezone.php
http://us.php.net/manual/en/datetimezone.construct.php

Perhaps the patch should be changed to catch the exception thrown when an unknown timezone string is passed. Something like:

  try {
    $tz_object = new DateTimeZone($to_tz);
  } catch (Exception $e) {
    drupal_set_message($e->getMessage());
  }

How do you feel about that?

alex_b’s picture

"Perhaps the patch should be changed to catch the exception thrown when an unknown timezone string is passed."

I think that's an excellent idea.

halstead’s picture

FileSize
1.64 KB

Okay I made it revert to the original behavior if the DateTimeZone object can't be created. I also added a PHP >= 5.2.0 requirement to the info file since date_timezone_set() was introduced in PHP 5.2 and exception handling was added in PHP 5.

Aron Novak’s picture

Status: Needs review » Reviewed & tested by the community

I tested it and it does not make any harm.
It should be committed for both 1.x and 2.x

alex_b’s picture

Nice work. RTBC from me, too.

halstead’s picture

Assigned: Unassigned » halstead
halstead’s picture

Status: Reviewed & tested by the community » Fixed

The problem has been resolved in a different manner (using timezone_open) in 6.x-1.3.

Status: Fixed » Closed (fixed)

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