Bug #42645 [Fbk->Nab]: getdate/mktime does not always add/subtract dst offset

Edit report at https://bugs.php.net/bug.php?id=42645&edit=1 ID: 42645 Updated by: requinix@php.net Reported by: carstenklein at yahoo dot de Summary: getdate/mktime does not always add/subtract dst offset -Status: Feedback +Status: Not a bug Type: Bug Package: Date/time related Operating System: Linux Ubuntu PHP Version: 5.2.4 -Assigned To: derick +Assigned To: Block user comment: N Private report: N New Comment: Alright. Then after almost 8 years of this bug being around, I'm going to close this as NAB. Here's why: The most important thing is that 1981-03-29 02:30:00 is not a valid time (in that timezone). It does not exist. See how the code tries to use 2:30 for the start time but the actual printout says 3:30? The most reasonable interpretation of 2:30 is "2 hours 30 minutes after midnight", but because of daylight savings and the jump from 1:59:59 to 3:00:00, that time turns out to be 3:30 AM. If you add whatever day interval to that then you're still going to get 3:30 AM because (1) it didn't start at 2:30 and (2) all "+N days" does is add N to the day number, then potentially adjust for wrapping out-of-bounds numbers and such (eg, 3/29 +3 days = 3/32, which wraps to 4/1). So you can't actually start with a datetime of 1981-03-29 02:MM:SS. You can, however, simulate that by using mktime() *and adding your day interval at the same time*. As in mktime(2, 30, 0, 3, 29 + 3, 1981) // adding the day at this point http://3v4l.org/8ob1c By doing that you bypass the "invalid time" problem but still make use of the "adjust for wrapping" feature. It also more closely reflects the logical process of "take this date and add 3 days to it" that a human would follow. Previous Comments: ------------------------------------------------------------------------ [2015-04-08 14:17:26] carstenklein at yahoo dot de Yes, it does reproduce the issue, the error occurs with older PHP versions I believe. Timezone: Europe/Amsterdam Expected: 1981-03-28 02:30:00 + 3 days = 1981-03-31 02:30:00 Actual: 1981-03-28 02:30:00 + 3 days = 1981-03-31 02:30:00 Expected: 1981-03-29 02:30:00 + 3 days = 1981-04-01 02:30:00 Actual: 1981-03-29 03:30:00 + 3 days = 1981-04-01 03:30:00 <--- ERR Expected: 1981-03-30 02:30:00 + 3 days = 1981-04-02 02:30:00 Actual: 1981-03-30 02:30:00 + 3 days = 1981-04-02 02:30:00 ------------------------------------------------------------------------ [2015-04-08 14:14:55] carstenklein at yahoo dot de I do not know whether this would reproduce it, as there is an error preventing the script from running: Timezone: Fatal error: Call to undefined function date_default_timezone_get() in /in/ddo01 on line 3 Process exited with code 255. ------------------------------------------------------------------------ [2015-04-08 08:52:58] requinix@php.net Could be there is a bug, yes. Mostly the No Feedback status means that the reporter did not answer someone's question. A question such as "does this latest snapshot fix your problem?" There's a ton of irrelevant output and crazy looking code that's a chore to sift through, so to be clear: The bug you're reporting is that spring leap date-times like 1981-03-29 2:30 AM, plus an interval of some number of days, results in a time that's 3:30 AM, while other days around then remain as 2:30? Does this repro it? http://3v4l.org/ddo01 ------------------------------------------------------------------------ [2015-04-08 07:52:10] carstenklein at yahoo dot de 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). ------------------------------------------------------------------------ [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". ------------------------------------------------------------------------ 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