Closed (fixed)
Project:
Feed Element Mapper
Version:
6.x-1.x-dev
Component:
Code
Priority:
Minor
Category:
Bug report
Assigned:
Reporter:
Created:
10 Jul 2009 at 00:07 UTC
Updated:
3 Dec 2009 at 22:40 UTC
Jump to comment: Most recent file
Comments
Comment #1
alex_b commentedThis seems to be fixed now - duplicate of ? #504852-4: Warning in feedapi_mapper_date.inc
Comment #2
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 commented#2 - thank you. Good catch. Can you explain what your patch fixes?
Comment #4
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 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 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 commentedNice work. RTBC from me, too.
Comment #9
halstead commentedComment #10
halstead commentedThe problem has been resolved in a different manner (using timezone_open) in 6.x-1.3.