|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #35887 wddx_deserialize not parsing dateTime fields properly
Submitted: 2006-01-03 21:27 UTC Modified: 2006-01-04 22:41 UTC
From: mattsch at gmail dot com Assigned: derick (profile)
Status: Closed Package: Feature/Change Request
PHP Version: 5.1.1 OS: Gentoo
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: mattsch at gmail dot com
New email:
PHP Version: OS:


 [2006-01-03 21:27 UTC] mattsch at gmail dot com
wddx_deserialize does not parse the dateTime like it did in php 5.0.4.  5.0.4 parsed the dateTime into a unix timestamp.  5.1.1 does not convert it and keeps it as this format: 2006-1-6T0:0:0-8:0

Reproduce code:
$eventsXML = wddx_deserialize(file_get_contents($eventsXMLFile));
echo $eventsXML['eventDate'][$i];

Expected result:
Output a unix time stamp like php 5.0.4.

5.0.4 format: 1136534400
5.1.1 format: 2006-1-6T0:0:0-8:0

Actual result:
Outputs incorrect format for datetimes: 2006-1-6T0:0:0-8:0


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2006-01-03 23:12 UTC] mattsch at gmail dot com
On php 5.0.4 this script outputs: 1136534400
On php 5.1.1 this script outputs: 2006-1-6T0:0:0-8:0

$eventsXML = "<wddxPacket version='1.0'><header/><data><recordset rowCount='1' fieldNames='eventDate' type='coldfusion.sql.QueryTable'><field name='eventDate'><dateTime>2006-1-6T0:0:0-8:0</dateTime></field></recordset></data></wddxPacket>";
$eventsXML = wddx_deserialize($eventsXML);
echo $eventsXML['eventDate'][0];
 [2006-01-03 23:43 UTC]
2006-1-6T0:0:0-8:0 is not a valid wddx format (which follows ISO8601,
 [2006-01-03 23:53 UTC] mattsch at gmail dot com
This not bogus!  PHP 5.0.4 parses this date.  It doesn't matter if it's not the proper iso format.  Allaire made wddx in Coldfusion and it has been outputting dates in that format since day 1.  Take a look at this link which is what coldfusion wddx outputs: (This server is running Coldfusion MX 6.1)
 [2006-01-04 00:04 UTC] mattsch at gmail dot com
Taken from

Date-time values-
Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0. Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed. While timezone information is optional, it must be successfully parsed and used to convert to local date-time values. Efforts should me made to ensure that the internal representation of date-time values does not suffer from Y2K problems and covers a sufficient range of dates. In particular, years must always be represented with four digits.
 [2006-01-04 00:48 UTC] mattsch at gmail dot com
Also note under Time zone processing:

Date-time values in WDDX are represented using a subset of the ISO8601 format. Time zone information is represented as an hour/minute offset from Coordinated Universal Time (UTC); for example, "2002-9-8T12:6:26-4:0".
 [2006-01-04 01:47 UTC]

Which is the one PHP works fine with. (Even PHP 4.3.11 worked)
 [2006-01-04 02:51 UTC] mattsch at gmail dot com
Again this is not bogus.  Coldfusion does not output leading zeros.  PHP 5.0.4 runs this code fine.  On PHP 5.1.1, I get notices because it no longer parses the dateTime into a unix timestamp.  Why is it so hard to fix this bug and make it work like it did in PHP 5.0.4?  On the wddx DTD, it makes this statement: Note that single-digit values for months, days, hours, minutes, or seconds do not need to be zero-prefixed.
 [2006-01-04 02:54 UTC] mattsch at gmail dot com
At the very least since you guys seem willing to break backwards compatibility, make a note of it in the PHP docs that as of PHP 5.1.1, wddx dateTimes serialized with coldfusion will no longer be deserialized into unix timestamps as they previously were under PHP 5.0.4.
 [2006-01-04 03:04 UTC] mattsch at gmail dot com
Here's the code from this link: 

<cfquery name="getTitles" datasource="#request.dsn#">
SELECT startDate, eventID, (SELECT categoryID FROM categories WHERE cLink LIKE '/events/content%' LIMIT 0, 1) AS categoryID
FROM events
WHERE display = 1 AND endDate >= '#LSDateFormat(Now(), "yyyy-mm-dd")#'
ORDER BY startDate, eventOrder
<cfwddx action="cfml2wddx" input="#getTitles#" output="wddxXML">
</cfsilent><cfheader name="Content-Type" value="text/xml;charset=utf-8"><?xml version="1.0" encoding="UTF-8"?>

You'll notice that Coldfusion produces the output using the cfwddx tag.  So you will be breaking compatibility with Coldfusion wddx when you don't fix this bug.
 [2006-01-04 09:41 UTC]
I did some investigations. states (written by allaire, which was bought by macromedia):
"Date-time values are encoded according to the full form of ISO8601, e.g., 1998-9-15T09:05:32+4:0."

All documents on ISO8601 (including the standard) only give this format:
Single digits are not allowed. So the WDDX DTD is flawed itself, it doesn't do what it says it does (ie. They say they use full ISO8601, but they don't). I find that incredible stupid.

I am marking this as a feature request for now, I do have a patch but I want to see its performance impacts on the parser first before committing it. It might not make it into PHP 5.1.2.
 [2006-01-04 17:35 UTC] mattsch at gmail dot com
I also looked at ISO 8601 and even previous versions because the DTD was written in 1999, but I couldn't find any mention of truncating leading zeros in the standard despite the fact that the wddx DTD says it's possible.  Thanks for implementing a patch to keep compatibility nevertheless.
 [2006-01-04 22:41 UTC]
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
Thank you for the report, and for helping us make PHP better.

Fixed for 5.1.2 and later
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 04:01:28 2024 UTC