ID: 22468 Updated by: [EMAIL PROTECTED] Reported By: stuart at myrddraal dot demon dot co dot uk -Status: Open +Status: Bogus Bug Type: XMLRPC-EPI related Operating System: Gentoo Linux PHP Version: 4.3.0 New Comment:
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. Previous Comments: ------------------------------------------------------------------------ [2003-02-28 03:35:55] stuart at myrddraal dot demon dot co dot uk 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 -- ------------------------------------------------------------------------ [2003-02-28 01:57:36] [EMAIL PROTECTED] 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. ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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
