ID:               22468
 User updated by:  stuart at myrddraal dot demon dot co dot uk
 Reported By:      stuart at myrddraal dot demon dot co dot uk
 Status:           Open
 Bug Type:         XMLRPC-EPI related
 Operating System: Gentoo Linux
 PHP Version:      4.3.0
 New Comment:

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


Previous Comments:
------------------------------------------------------------------------

[2003-02-28 00:21:48] [EMAIL PROTECTED]

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

------------------------------------------------------------------------

[2003-02-27 21:10:16] stuart at myrddraal dot demon dot co dot uk

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

------------------------------------------------------------------------

[2003-02-27 20:57:07] stuart at myrddraal dot demon dot co dot uk

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

------------------------------------------------------------------------

[2003-02-27 20:36:00] [EMAIL PROTECTED]

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. 

------------------------------------------------------------------------

[2003-02-27 18:54:52] stuart at myrddraal dot demon dot co dot uk

The XML-RPC Extension does not correctly cope with dates before the
Epoch (ie, anything which won't go into time_t).

This bug prevents the XML-RPC Extension passing the XML-RPC
verification suite, which can be found at http://validator.xmlrpc.com/

The following example code demonstrates the fault.

<?php

$l_szDate = "19040401T19:01:02";
xmlrpc_set_type ($l_szDate, "datetime");

echo xmlrpc_encode_request(null, $l_szDate);

?>

------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=22468&edit=1

Reply via email to