Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

This is a bug in libxmlrpc and not PHP. 

Hi there,

I'm surprised that you don't want to accept this bug.  I don't agree that this bug isn't a PHP bug.  Any chance of you reconsidering?

1. PHP ships with its own (forked!) copy of libxmlrpc.  PHP users like myself don't go and get it from the XMLRPC-EPI project.
2. Any fix for this fault will have to be applied to PHP's CVS tree.
3. The PHP team actively investigate faults in other Extensions that are built on underlying libraries.
4. Until the bug is fixed, PHP's support for XML-RPC is not standards-compliant.

Best regards,
Stu

If it helps, the cause of the bug appears to be a design flaw in libxmlrpc.  libxmlrpc converts dateTime strings into the time_t type.  On POSIX.1 compliant systems, time_t can't legally hold values earlier than the Epoch.

Fixing libxmlrpc to use a different type won't be enough to support dateTime natively under PHP.  PHP doesn't have any native date / time functions that can work with dates earlier than the Epoch.

Best regards,
Stu

What are you talking about?  PHP handles negative time_t's
perfectly.  Try this:

        $t = -987654321;
        echo date("M d Y H:i:s",$t);

You will see it outputs:

Sep 14 1938 11:34:39

Hi Rasmus,

Sorry, my mistake.  But what about converting back the otherway?

echo mktime("11", "34", "39", "14", "09", "1938");

produces -1, not -987654321.  strtodate() does no better.

PHP's handling of time_t is not the issue.  time_t itself is the issue.  Negative time_t's won't be generated by the underlying libc.  If you try, you get an error back.

The XML-RPC Extension does not trap this error.  It replaces the valid dateTime valid with the error code.  The Extension  can *corrupt* data sent over XML-RPC.  That's why it currently does not pass the XML-RPC Validator tests.

And there isn't an alternative to time_t for the Extension to use.

(From the strtodate() PHP manual page:)
Note:  The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT.

UNIX timestamps start at 0 for the Epoc (0:00:00 1st Jan 1970).  The manual page is wrong.

Best regards,
Stu

Hi again, Rasmus,

Sorry, should have included this in the last addition to this bug report.

POSIX.1-1990.  Section 2.2.2.77: seconds since the Epoch

"If the year < 1970 or the value [of seconds since the Epoch] is negative, the relationship is undefined.  If the year >= 1970 and the value is non-negative, the value is related to a Coordinated Universal Time name ..."

This means that anywhere in PHP that uses (or intends to use) negative time_t as a valid time is relying on undefined behaviour.

I had a look at the source code for PHP's date and time functions.  

PHP's mktime() command (as documented) manipulates the year field before calling the underlying libc call.  All of these underlying calls will not return a negative time_t.  If PHP intends to support timestamps < 1970 (and why not?), you can't use these libc calls to do so.

PHP's date() command ultimately makes a call to libc's gmtime_r(), the thread-safe version of gmtime().  If libc's gmtime_r() ever checks for negative time_t as an invalid input, PHP's date() command will not cope with negative time_t either.

--

I feel like I'm having to do a *lot* of work to get you to accept that these problems exist.  Is there a reason for this?

Best regards,
Stu

So use Julian if you need to deal with old dates.  We are not going to change the basic date/time handling in PHP.  If libxmlrpc needs to be changed to work with Julian dates, ask them about it and we will incorporate their changes when they do so.

Hi Rasmus,

Using Julian Day Count is a good suggestion.  It's not part of every PHP installation, but that's a different problem.

Unfortunately, that format is no good until the XML-RPC Extension is fixed to stop corrupting dateTimes < 1970.

For future reference, I've logged the bug with the XMLRPC-EPI project on SourceForge:

http://sourceforge.net/tracker/index.php?func=detail&aid=694927&group_id=23199&atid=377728

Best regards,
Stu
--

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

PHP's own date conversion has nothing to do with this. The conversion is done via xmlrpc's own string -> timestamp conversion function. As far as the library itself, it is very close to the original lib and if the non-bundled libxmlrpc were to introduce a fix for this bug I assure you it would be backported to the bundled (with php) library as well. Hence, this bug should be directed towards the developers of libxmlrpc rather the PHP developers.