ID: 22468
Updated by: [EMAIL PROTECTED]
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:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-02-28 01:52:38] stuart at myrddraal dot demon dot co dot uk
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
------------------------------------------------------------------------
[2003-02-28 00:48:01] stuart at myrddraal dot demon dot co dot uk
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
------------------------------------------------------------------------
[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
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22468
--
Edit this bug report at http://bugs.php.net/?id=22468&edit=1
