Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.5.0a4
Bug #12420 Date constructor handles iso 8601 timezone offests of zero incorrectly
Submitted: 2007-11-11 06:07 UTC
From: gauthierm Assigned: c01234
Status: Closed Package: Date (version 1.4.7)
PHP Version: 5.2.4 OS: Irrelevant
Roadmaps: (Not assigned)    
Subscription  


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 24 - 13 = ?

 
 [2007-11-11 06:07 UTC] gauthierm (Michael Gauthier)
Description: ------------ The Date constructor assumes 'zero' timezone offsets are offset from the default time zone, not from UTC. The setDate() method calls toUTCbyOffset() when a UTC offset is specified in an ISO 8601 date. This in turn calls toUTC() when the offset is Z, +00:00 or +0000. If the default time zone is not UTC, toUTC() converts from the default time zone to UTC, causing an offset. Time offsets are relative to UTC in the ISO 8601 spec. Using setTZ('UTC') instead of toUTC() inside the toUTCbyOffset() method is the correct way to handle 'zero' offsets. Test script: --------------- Date_TimeZone::setDefault('America/Halifax'); $date = new Date('2000-01-01T00:00:00.0000Z'); echo $date->format('%T'); Expected result: ---------------- 00:00:00 Actual result: -------------- 04:00:00

Comments

 [2007-11-16 23:47 UTC] c01234 (Chuckie Chuck)
I have amended toUTCbyOffset() in CVS, but also setDate() so that it does not call this function any more anyway.
 [2007-11-18 19:06 UTC] gauthierm (Michael Gauthier)
The changes made in CVS look great! Feel free to close this bug.
 [2008-03-23 23:10 UTC] c01234 (Chuckie Chuck)
Thank you for your bug report. This issue has been fixed in the latest released version of the package, which you can download at http://pear.php.net/get/Date