ID: 48092
User updated by: kenny at tnsnurse dot com
Reported By: kenny at tnsnurse dot com
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows Server 2000
PHP Version: 5.2.9
New Comment:
Thanks for your comment and the link. "Bogus" may be the wrong word for
my description of the logic, but it is also wrong for this status; for
many people this was an undesirable (and unneeded) change. There are
probably billions of lines of legacy code that stored dates with
previous versions of PHP (in whatever time zone) and people expected to
get those same dates back with PHP 5. That is not what happens. Second,
and perhaps more to-the-point, MySQL never fails to return the correct
date based on my time zone. Since PHP and MySQL have long been linked as
the ideal developer solution, one would not expect them to return
different results for dates when both are set to the same time zone. And
I still object to the absence of a simple switch that allows the
developer to turn DST off.
In the meantime, MY work-around is to set the date_timezone setting in
the php.ini file to "America/Belize" which in effect maintains my
timezone at CST year 'round. This yields compatibility with the dates
that are *already stored* in our system and which I'm not willing to
convert because I have bigger things to do. Most countries nearer the
equator don't need to use DST. So my rec for people bitten by this DST
thing is to find a country due south of you that doesn't use DST. Then
use that timezone setting.
It is apparent from reading many other posts on this (which you've
closed) that you do not want to, or cannot decide how to, deal with it.
Looking at it from a strictly academic standpoint, I'm sure your
reasoning is valid. However, most of us are trying to help run a
business and don't have the luxury of telling our boss that it's
academically correct.
Previous Comments:
------------------------------------------------------------------------
[2009-05-14 14:21:27] der...@php.net
Not understanding things doesn't make the logic bogus. For example,
Unix timestamps (like the big fancy number that you posted) are always
in UTC (seconds since 1970-01-01 00:00 UTC). In case you have a timezone
selected, it might shift to/from DST during your "calculation" and it
fucks up because you're doing it wrong. For me, the code you gave
shows:
$ php -r 'echo date("M j, Y H:i", (1237787999 - 86400));'
Mar 22, 2009 06:59
which is perfectly okay. So two things:
1. Set the proper time zone
2. Use proper code like:
<?php
$d = date_create( "@1237787999" )->modify( "-1 day" );
echo $d->format( 'M j, Y H:i' ), "\n";
?>
3. If you really want to know how all this stuff works:
http://phpdatebook.com
------------------------------------------------------------------------
[2009-05-14 13:38:27] kleeh at bellsouth dot net
This is one of a number of reasons -- but the most important one --
that we cannot switch to PHP 5. Apparently this guy can't either, or he
has and he's discovered the bug too late.
Is there not a work-around for this in PHP 5 -- one that doesn't
involve changing massive amounts of logic? You guys usually do a great
job. This looks like it slipped through the cracks.
------------------------------------------------------------------------
[2009-04-27 22:20:24] kenny at tnsnurse dot com
Description:
------------
We do not need PHP to "force" us into accepting its Daylight Savings
Time calculations. Both our database and web boxes are set to Standard
time and we never switch them to DST. We don't WANT PHP's DST logic
screwing with our dates because we don't care about DST when we're
posting, reading, echoing, or even doing date diffs. But I don't see any
way in 5.2.9 to tell it to ignore DST -- you're even deprecating the one
switch that seemed to work in PHP 4.3. So if you're going to do that, we
need a switch or an ini file parameter to tell PHP to ignore DST.
Reproduce code:
---------------
date("M j, Y H:i", (1237787999 - 86400). Exact code is << echo ">Week
#{$row->periodid} WE " . date("M j, Y H:i", ($row->enddate - 86400)) >>.
I gave you the 1237787999 as an example of a date we're retrieving from
mysql.
Expected result:
----------------
I expect to see March 21, 2009 23:59:59, unless you've redefined the
mathematical result of 24 * 60 * 60.
Actual result:
--------------
The actual, "echoed-to-the-screeen" result of this is March 22, 2009
00:59:59. In what universe is this correct? The "1237787999" is an
example of a correct date on our mysql database (returned in a variable
and echoed) and it is the unix timestamp representation of March 22,
2009 23:59:59. If I subtract 86400 (which USED to be 24 hours) from
that, I should get March 21, 2009 23:59:59. This should be simple
arithmetic; I should not have to put up with PHP's DST stuff in doing
this.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=48092&edit=1
