Error when mapping timestamps to cck date fields
halstead - July 10, 2009 - 00:07
| Project: | Feed Element Mapper |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | halstead |
| Status: | fixed |
Description
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);
#1
This seems to be fixed now - duplicate of ? #504852-4: Warning in feedapi_mapper_date.inc
#2
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.
#3
#2 - thank you. Good catch. Can you explain what your patch fixes?
#4
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?
#5
"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.
#6
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.
#7
I tested it and it does not make any harm.
It should be committed for both 1.x and 2.x
#8
Nice work. RTBC from me, too.
#9
#10
The problem has been resolved in a different manner (using timezone_open) in 6.x-1.3.