Edit report at https://bugs.php.net/bug.php?id=42645&edit=1
ID: 42645
Comment by: carstenklein at yahoo dot de
Reported by: carstenklein at yahoo dot de
Summary: getdate/mktime does not always add/subtract dst
offset
Status: No Feedback
Type: Bug
Package: Date/time related
Operating System: Linux Ubuntu
PHP Version: 5.2.4
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
No feedback does not mean that the bug does not exist. Especially when one provided code to actually
reproduce it.
BTW the issue still exists. Currently testing this with
PHP 5.6.7-1 (cli) (built: Mar 24 2015 12:30:15).
Previous Comments:
------------------------------------------------------------------------
[2008-11-10 01:00:05] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
------------------------------------------------------------------------
[2008-11-02 13:03:37] jani@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
------------------------------------------------------------------------
[2007-10-17 20:12:27] carstenklein at yahoo dot de
Additional information:
it seems as if the timelib or some component thereof behaves like a clock that will only adjust the
dst when transitioning from the day that the transition is being scheduled for depending on the
current timezone setting.
This is actually hard to figure out since the information required to find out whether there is a
scheduled dst transition on a particular date is actually not available from within php, AFAIK.
A more sophisticated application therefore must replicate the timezone database along with all the
code in order to find out whether or not a dst transition should take place on a particular date.
Here are a few pointers as to how this problem could actually be solved:
a) make available dst transitioning dates via the date/time api in order for the user to find out
whether or not on a particular date a dst transition will take place
or
b) leave it to the user whether or not to take care of dst transitioning by altogether removing
existing behaviour
the latter would actually break with existing applications, therefore,
the initial proposal of reusing the obsoleted seventh parameter to mktime for indicating whether or
not dst should be applied seems to be the less painful one. additionally, a) should also be taken
into consideration in order for the user not having to reimplement a timezone database along with
all the possible transition dates for applying or removing dst.
Hope this helps with your task.
Regards
Carsten
------------------------------------------------------------------------
[2007-09-13 08:09:47] jani@php.net
Assigned to the ext/date maintainer. :)
------------------------------------------------------------------------
[2007-09-12 18:04:30] carstenklein at yahoo dot de
Small err on my behalf, where it reads:
"result often are non reproducible and may seem quite random"
it must read:
"result are reproducible but may seem quite random"
and
"Therefore I urge you to at least provide a timezone offset less version of mktime in order to
at least get some reproducible results."
it should read
"Therefore I urge you to at least provide a timezone offset less version of mktime and let the
user do the rest."
A provable solution would be to take the seventh, now deprecated parameter to mktime and make it a
flag indicating wether or not offsets will be applied to the resulting date/time.
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=42645
--
Edit this bug report at https://bugs.php.net/bug.php?id=42645&edit=1