Good day,
I would like to bring up a few issues regarding negative timestamps.
Firstly, I think it would be good to compose a document that discusses
UNIX timestamps and the support or lack thereof regarding negative
timestamps on various systems. For example, what is it about a system
that gives it negative timestamp support as opposed to not? This
document needs to be very clear because there is a lot of FUD floating
around on the web about this. Once such a document has been composed,
every PHP date function should have the following note:
"WARNING: the range of dates that the PHP date functions can handle are
dependent on your system's implementation of UNIX timestamps. Please
click here [link to timestamp document] for more information."
You can then remove all the little notes that are scattered through the
function docs regarding windows timestamp support and pre-1970 and so
on.
Now I would like to discuss the documentation for strftime. In the docs,
I see this:
"Additionally, not all platforms support negative timestamps, therefore
your date range may be limited to no earlier than the Unix epoch. This
means that e.g. %e, %T, %R and %D (there might be more) and dates prior
to Jan 1, 1970 will not work on Windows, some Linux distributions, and a
few other operating systems."
This statement is somewhat misleading because as far as I can tell, negative
timestamps are not supported AT ALL for strftime. Looking inside the
function definition for strftime in php-4.3.5/ext/standard/datetime.c, I
see this code following the extraction of the function arguments:
843 if (timestamp < 0) {
844 RETURN_FALSE;
845 }
Unless I am missing something, this means that strftime always returns
false when working with negative timestamps. As a brief aside, I
commented out line 844, recompiled, and tried calling strftime with a
negative timestamp - it returned the correct result. I am assuming there
is a reason to disallow negative timestamps in this function, but there
are no comments in the code to suggest why. As another documentation
item, it would be nice to have something like:
843 // disallow negative timestamp b/c [INSERT REASON HERE]
844 if (timestamp < 0) {
845 RETURN_FALSE;
846 }
Back to the strftime docs, I see a user comment:
"Note that on Linux kernels before 2.4.* the date functions in PHP will
happily accept a date before 01-01-1970 as stated at the top of this man
page, post kernel 2.4.* the date functions *do not* work with dates
before 1970.
If you've existing scripts doing date validation on dates before 1970,
check them before you upgrade your kernel!"
Is this for real? And looking on a site that offers a date function
package: http://php.weblogs.com/adodb_date_time_library I see this:
"Since RedHat 7.3, negative timestamps are not supported in glibc. So
the latest versions of this library will take over negative timestamp
calculations on all platforms."
So where does the problem lie? Is it in the kernel, glibc, or both?
Another thing that needs to be documented is which functions support
negative timestamps and which do not. strftime obviously does not. This
appears to work on my Redhat 8 system:
date("d/m/Y", -1735281789)
and yet the following returns -1:
strtotime("-50 years");
Though it works on older versions of Redhat. So if my system does not
support negative timestamps, why does date() operate correctly with a
negative timestamp? And why can I correctly run a C program that uses a
negative timestamp:
#include <time.h>
#include <stdio.h>
main() {
time_t t = -1735281789;
printf("%s\n",ctime(&t));
char s[80];
const struct tm *nowstruct;
nowstruct = localtime(&t);
strftime(s, 80, "%m/%d/%Y", nowstruct);
printf("%s\n",s);
}
Produces output:
Tue Jan 5 12:16:51 1915
01/05/1915
My sysadmins want to upgrade the production servers, but we have a massive
amount of legacy PHP code that uses the date functions all over the place.
Without more in-depth documentation of the PHP functions with regards to
these timestamp issues, I cannot know what code is safe to leave alone and
what code must be changed. Due to the nature of this code, the less I
touch it, the better.
I would happy to contribute in any way possible with regards to this matter.
Thanks,
Ross
