Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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);
Comment | File | Size | Author |
---|---|---|---|
#6 | feedapi_mapper-515190.patch | 1.64 KB | halstead |
#2 | feedapi_mapper-515190.patch | 915 bytes | halstead |
Comments
Comment #1
alex_b CreditAttribution: alex_b commentedThis seems to be fixed now - duplicate of ? #504852-4: Warning in feedapi_mapper_date.inc
Comment #2
halstead CreditAttribution: halstead commentedI 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.
Comment #3
alex_b CreditAttribution: alex_b commented#2 - thank you. Good catch. Can you explain what your patch fixes?
Comment #4
halstead CreditAttribution: halstead commentedRight 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:
How do you feel about that?
Comment #5
alex_b CreditAttribution: alex_b commented"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.
Comment #6
halstead CreditAttribution: halstead commentedOkay 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.
Comment #7
Aron NovakI tested it and it does not make any harm.
It should be committed for both 1.x and 2.x
Comment #8
alex_b CreditAttribution: alex_b commentedNice work. RTBC from me, too.
Comment #9
halstead CreditAttribution: halstead commentedComment #10
halstead CreditAttribution: halstead commentedThe problem has been resolved in a different manner (using timezone_open) in 6.x-1.3.