Am using the strtotime function to find the difference between two given dates like this:
$diff_in_mill_seconds = strtotime($ToDate) - strtotime($FromDate);
$difference_in_years = round($diff_in_mill_seconds / (365*60*60*24),1);
This script fails when the $ToDate is beyond 2038-01-19.
The official PHP Documentation says:
The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC
The PHP Documentation also says:
Using this function for mathematical operations is not advisable. It is better to use DateTime::add() and DateTime::sub() in PHP 5.3 and later, or DateTime::modify() in PHP 5.2.
I cannot use DateTime::add() and DateTime::sub() as the PHP version on the server is 5.2.
So, how do I calculate the difference between two dates (beyond 2038-01-19) in years using php 5.2?
It's the UNIX Y2K38 bug. It has been fixed in 64bit implementations of PHP or by using DateTime::diff, which does not use integers internally and hence does not suffer from the problem.
You need either. There's no real fix without switching platforms.
Related
Currently I'm converting all my PHP unix timestamps to work beyond 2k38 issue.
I noticed that setcookie() expire date parameter uses the unix timestamp. Is there a way to set expire date with alternative method, maybe using the DateTime class somehow?
From the PHP document about expire date:
Note: You may notice the expire parameter takes on a Unix timestamp,
as opposed to the date format Wdy, DD-Mon-YYYY HH:MM:SS GMT, this is
because PHP does this conversion internally.
You cannot change the function signature. Well, not at least without fiddling with strange PHP extensions. But since the cookie spec does not use Unix timestamps at all you can simply write your own function and call header() manually:
Set-Cookie: lang=en-US; Expires=Wed, 09 Jun 2099 10:18:14 GMT
Set-Cookie: lang=en-US; Max-Age=8640000
... and hope that browsers are able to process the date:
If the expiry-time is later than the last date the user agent can
represent, the user agent MAY replace the expiry-time with the last
representable date.
Or you can simply use seecookie() anyway. As far as I know, it'll only be an issue in some 32-bit versions of PHP.
I wrote an application in PHP that connects to a SQL server.
If this application runs on windows it uses srvsql libraries, in linux case it uses sybase libraries.
My trouble is that date fields outputs of sql server are not the same, with srvsql i get something like '2012-12-10 12:14:26.067'. With sybase i get 'Dec 10 2012 12:14:26:067PM '!
How can i set sybase connection to get the SAME output format without changing every query?
I've been looking for a good solution to this for a few hours now myself. While I would love to handle this php side it just isn't an option in my current case as a 3rd party library is processing the data. The solution I just stumbled upon is on the query side.
The rough idea is convert the date to a string before the results are returned so the libraries (mssql and sqlsrv in my case) don't have the opportunity to muk with the results.
CONVERT(nvarchar(30), myDate, 121) AS date
121 is yyyy-mm-dd hh:mi:ss.mmm(24h)
Other options can be found in Microsoft's documentation.
Edit
Found this the other day. Haven't experimented with it but the mssql library has a setting to tell it what to do with dates: mssql.datetimeconvert = On. There may be a way in php.ini to make both libraries render the date in the same format. I'm too far into the convert solution to switch over now but it would be worth some experimentation if someone is reading this for the first time.
Instead of worrying about the date format that comes back from the different databases, consider handling it PHP-side.
Both of those formats, (2012-12-10 12:14:26.067 and Dec 10 2012 12:14:26:067PM) are recognized by PHP. When passed into a DateTime object, they work as expected. From the PHP interactive prompt:
php > $dt = new DateTime('Dec 10 2012 12:14:26:067PM');
php > echo $dt->format('r u'), "\n";
Mon, 10 Dec 2012 12:14:26 -0800 067000
php >
php > $dt = new DateTime('2012-12-10 12:14:26.067');
php > echo $dt->format('r u'), "\n";
Mon, 10 Dec 2012 12:14:26 -0800 067000
If you need a refresher, r is the format code for an RFC 2822 date, while u is the format code for microseconds, which only work with DateTimes.
By switching to DateTimes, you can easily juggle between input formats and basically never have to worry about it. DateTime uses the strtotime parsing rules. You'll want to understand their limitations, but you generally won't bump up against them.
I want to convert 12/31/2099 to Unix time using PHP. I tried strtotime('12/31/2099') but the function returns null.
I tried converting it to Unix time using an online conversion tool which gives 4102358400 which, when turned into a date gives 01/18/2038.
How can I convert dates to Unix time and again convert it back to a readable format like 12/31/2099?
In old versions of PHP ( < 5.1.0), strtotime supported a max date of Tue, 19 Jan 2038 03:14:07 UTC. To bypass this limitation, upgrade to 5.1.0 or later.
64-bit versions are unaffected by this limitation.
For more information, see the Notes: at http://www.php.net/strtotime
32-bit Unix timestamps run out in 2038, so if you're on a 32-bit system, that would cause a problem.
The unix timestamp of a point in time is the number of seconds since 1970-01-01 00:00:00 UTC to this point in time. On 2038-01-18 this will overflow a 32bit signed int - call it the Y2K bug of the unices.
Mind though, that this is a problem of the implementation, not the algotithm: Most current implementations use an unsigned 32bit int, but it is to be expected that 32bit ints will be a thing of the past some time before 2038
Usual workarounds include an if-branch to detect whether a date is after the wraparound and adjust accordingly.
I am using PHP and jQuery to build an interactive timeline which needs to display dates between 1500 and 2020. I usually use PHP's strtotime function when working with dates, but it does not work for dates pre-1900.
The dates will come from a MySQL database, and are formatted as strings such as "January 31, 1654" (this may not be the ideal format, but I can't change how they are stored). I am using PHP to parse the dates, basically converting them into pixel values which determine where they are displayed on the timeline.
What is the easiest way to parse these historical dates?
The DateTime class, here, might help (quoting):
Each component of date (e.g. year) is
internally stored as 64-bit number so
all imaginable dates (including
negative years) are supported.
But note that:
It's only exists in PHP >= 5.2
And several methods only exist in PHP >= 5.3
So: beware of which methods you're using, if you're developping on PHP 5.3 and want your software to be compatible with PHP 5.2
Another solution (especially, if using Zend Framework in your application) would be the Zend_Date component (quoting):
Although PHP 5.2 docs state, "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," Zend_Date supports a
nearly unlimited range, with the help
of the BCMath extension
Using the wonderful Carbon Library, dates in the past are not a problem:
$date = Carbon::now();
$date->subCenturies(23);
echo $date->format('Y-m-d');
// -0282-03-15
This works for dates where humans have been around. For everything else, using a date (with day and month, set on the AC/BC scale) does not make a lot of sense.
I need to calculate the number of decades between 2 dates possible spanning form 1708 until today - the limitations are as far as I can gather are 1970/1901 within PHP native functions.
Can anyone advise?
Thanks!
If you have PHP >= 5.3.0:
$before = new DateTime('1708-02-02');
$decades = $before->diff(new DateTime())->y / 10;
You could use Zend_Date. It's part of the Zend Framework but can be used standalone, you don't need to install the whole framework to use it. It can work with dates beyond 1901 if the bcmath extension is installed into your PHP. From Zend_date's theory of operation:
This was only possible, because Zend_Date is not limited to UNIX timestamps nor integer values. The BCMath extension is required to support extremely large dates outside of the range Fri, 13 Dec 1901 20:45:54 GMT to Tue, 19 Jan 2038 03:14:07 GMT. Additional, tiny math errors may arise due to the inherent limitations of float data types and rounding, unless using the BCMath extension.
I like to recommend Zend components because they are well-groomed, high-quality code. There are other solutions to this, though, for example using the mySQL date functions.
I would write a custom method.
PHP date functions are based on the epoch ( 1969 ) so there won't be much help there.
If your just looking at years that is simple math
higher year - earlier year = years
years / 10 = decades.
If you mean decades from an even 01-10, 11-20 then you could do some rounding. (round early date up, later date down to nearest 10.