Bug #42645 [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: Not a bug Type: Bug Package: Date/time related Operating System: Linux Ubuntu PHP Version: 5.2.4 Block user comment: N Private report: N New Comment: Still daylight savings. Still time overflowing from 2:30 to 3:30. The spring DST dates for the first few of those years are: 1980: 4/6 1981: 3/29 1982: 3/28 1983: 3/27 1984: 3/25 http://www.timeanddate.com/time/change/germany/berlin?year=1980 All but the first (that I sampled) are still the exact same thing I described earlier: starting time overflowed to 3:30, thus the ending time stayed at 3:30. For the first one, the DST date was at the *end* of the period which is why the starting time was 2:30 but the ending time was 3:30. Previous Comments: ------------------------------------------------------------------------ [2015-04-16 20:50:34] carstenklein at yahoo dot de Here is another example running the original script for the Europe/Berlin timezone for a time span that certainly has DST in place. I wonder where these extra hours come from? Timezone: Europe/Berlin Testing Normal Time to DST Transition: 1980-03-17 02:30:30 + P0Y0M20DT0:0:0 + 1980-04-06 03:30:30 <- FAILURE 1981-03-29 03:30:30 + P0Y0M20DT0:0:0 + 1981-04-18 03:30:30 <- FAILURE 1982-03-28 03:30:30 + P0Y0M20DT0:0:0 + 1982-04-17 03:30:30 <- FAILURE 1983-03-27 03:30:30 + P0Y0M20DT0:0:0 + 1983-04-16 03:30:30 <- FAILURE 1984-03-25 03:30:30 + P0Y0M20DT0:0:0 + 1984-04-14 03:30:30 <- FAILURE 1985-03-31 03:30:30 + P0Y0M20DT0:0:0 + 1985-04-20 03:30:30 <- FAILURE 1986-03-30 03:30:30 + P0Y0M20DT0:0:0 + 1986-04-19 03:30:30 <- FAILURE 1987-03-29 03:30:30 + P0Y0M20DT0:0:0 + 1987-04-18 03:30:30 <- FAILURE 1988-03-27 03:30:30 + P0Y0M20DT0:0:0 + 1988-04-16 03:30:30 <- FAILURE 1989-03-26 03:30:30 + P0Y0M20DT0:0:0 + 1989-04-15 03:30:30 <- FAILURE 1990-03-25 03:30:30 + P0Y0M20DT0:0:0 + 1990-04-14 03:30:30 <- FAILURE 1991-03-31 03:30:30 + P0Y0M20DT0:0:0 + 1991-04-20 03:30:30 <- FAILURE 1992-03-29 03:30:30 + P0Y0M20DT0:0:0 + 1992-04-18 03:30:30 <- FAILURE 1993-03-28 03:30:30 + P0Y0M20DT0:0:0 + 1993-04-17 03:30:30 <- FAILURE 1994-03-27 03:30:30 + P0Y0M20DT0:0:0 + 1994-04-16 03:30:30 <- FAILURE 1995-03-26 03:30:30 + P0Y0M20DT0:0:0 + 1995-04-15 03:30:30 <- FAILURE 1996-03-31 03:30:30 + P0Y0M20DT0:0:0 + 1996-04-20 03:30:30 <- FAILURE 1997-03-30 03:30:30 + P0Y0M20DT0:0:0 + 1997-04-19 03:30:30 <- FAILURE 1998-03-29 03:30:30 + P0Y0M20DT0:0:0 + 1998-04-18 03:30:30 <- FAILURE 1999-03-28 03:30:30 + P0Y0M20DT0:0:0 + 1999-04-17 03:30:30 <- FAILURE 2000-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2000-04-15 03:30:30 <- FAILURE 2001-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2001-04-14 03:30:30 <- FAILURE 2002-03-31 03:30:30 + P0Y0M20DT0:0:0 + 2002-04-20 03:30:30 <- FAILURE 2003-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2003-04-19 03:30:30 <- FAILURE 2004-03-28 03:30:30 + P0Y0M20DT0:0:0 + 2004-04-17 03:30:30 <- FAILURE 2005-03-27 03:30:30 + P0Y0M20DT0:0:0 + 2005-04-16 03:30:30 <- FAILURE 2006-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2006-04-15 03:30:30 <- FAILURE 2007-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2007-04-14 03:30:30 <- FAILURE 2008-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2008-04-19 03:30:30 <- FAILURE 2009-03-29 03:30:30 + P0Y0M20DT0:0:0 + 2009-04-18 03:30:30 <- FAILURE 2010-03-28 03:30:30 + P0Y0M20DT0:0:0 + 2010-04-17 03:30:30 <- FAILURE 2011-03-27 03:30:30 + P0Y0M20DT0:0:0 + 2011-04-16 03:30:30 <- FAILURE 2012-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2012-04-14 03:30:30 <- FAILURE 2013-03-31 03:30:30 + P0Y0M20DT0:0:0 + 2013-04-20 03:30:30 <- FAILURE 2014-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2014-04-19 03:30:30 <- FAILURE 2015-03-29 03:30:30 + P0Y0M20DT0:0:0 + 2015-04-18 03:30:30 <- FAILURE 2016-03-27 03:30:30 + P0Y0M20DT0:0:0 + 2016-04-16 03:30:30 <- FAILURE 2017-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2017-04-15 03:30:30 <- FAILURE 2018-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2018-04-14 03:30:30 <- FAILURE 2019-03-31 03:30:30 + P0Y0M20DT0:0:0 + 2019-04-20 03:30:30 <- FAILURE 2020-03-29 03:30:30 + P0Y0M20DT0:0:0 + 2020-04-18 03:30:30 <- FAILURE 2021-03-28 03:30:30 + P0Y0M20DT0:0:0 + 2021-04-17 03:30:30 <- FAILURE 2022-03-27 03:30:30 + P0Y0M20DT0:0:0 + 2022-04-16 03:30:30 <- FAILURE 2023-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2023-04-15 03:30:30 <- FAILURE 2024-03-31 03:30:30 + P0Y0M20DT0:0:0 + 2024-04-20 03:30:30 <- FAILURE 2025-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2025-04-19 03:30:30 <- FAILURE 2026-03-29 03:30:30 + P0Y0M20DT0:0:0 + 2026-04-18 03:30:30 <- FAILURE 2027-03-28 03:30:30 + P0Y0M20DT0:0:0 + 2027-04-17 03:30:30 <- FAILURE 2028-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2028-04-15 03:30:30 <- FAILURE 2029-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2029-04-14 03:30:30 <- FAILURE 2030-03-31 03:30:30 + P0Y0M20DT0:0:0 + 2030-04-20 03:30:30 <- FAILURE 2031-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2031-04-19 03:30:30 <- FAILURE 2032-03-28 03:30:30 + P0Y0M20DT0:0:0 + 2032-04-17 03:30:30 <- FAILURE 2033-03-27 03:30:30 + P0Y0M20DT0:0:0 + 2033-04-16 03:30:30 <- FAILURE 2034-03-26 03:30:30 + P0Y0M20DT0:0:0 + 2034-04-15 03:30:30 <- FAILURE 2035-03-25 03:30:30 + P0Y0M20DT0:0:0 + 2035-04-14 03:30:30 <- FAILURE 2036-03-30 03:30:30 + P0Y0M20DT0:0:0 + 2036-04-19 03:30:30 <- FAILURE 2037-03-29 03:30:30 + P0Y0M20DT0:0:0 + 2037-04-18 03:30:30 <- FAILURE ------------------------------------------------------------------------ [2015-04-08 22:15:18] requinix@php.net Reply to the invalid thing first: >One more thing, though >1981-03-29 02:30:00 >is a very valid date and time. >Not so much >1981-02-29 02:30:00 >which I believe you had in mind. Not in the Europe/Amsterdam timezone, which is where the 3v4l code I posted is running. Their 1981 spring DST change was on 1981-03-29 and they went from 01:59:59 to 03:00:00. There was no 02:30:00 on that day. So, invalid. And the rest: >See the actual, it already has the timezone offset added to it. "Already" because the code tries to use 2:30, which isn't valid (for that date), and the most reasonable interpretation of that would be after the timezone offset change where it becomes 3:30. >$t = getdate( $date ) Not sure what you're trying to say with this... getdate() seems to be behaving as it should. http://3v4l.org/OCfb2 For the 28th and 30th there's nothing special, but for the 29th it does the same thing demonstrated in my code where it wraps 2:30 to 3:30. Because, again, invalid time (for that date). >which will already apply the dst offset on a rather random basis. DST was only applied in one place: when correcting the start time given for the 3/29 date. >Or rather not so much random as sunday is considered the first day of the week in some regions >of the world. Sunday being the first day or not is irrelevant to any of this: it's purely a matter of DST changes. ------------------------------------------------------------------------ [2015-04-08 21:18:18] carstenklein at yahoo dot de One more thing, though 1981-03-29 02:30:00 is a very valid date and time. Not so much 1981-02-29 02:30:00 which I believe you had in mind. ------------------------------------------------------------------------ [2015-04-08 21:14:40] carstenklein at yahoo dot de *) what is marked as FAILURE is actually correct, however, all the other dates before also transition from non-dst to dst, in the local configuration, i.e. CET to CEST, so these should also have a local time reading of 03:30:30 instead of just 02:30:30. considering the above, overall dst behaviour of getdate() seems to be off. and besides of that, if you feel happy with your current solution, go on with it as I have moved pass PHP and am no longer using it. ------------------------------------------------------------------------ [2015-04-08 21:10:04] carstenklein at yahoo dot de Or rather not so much random as sunday is considered the first day of the week in some regions of the world. Perhaps in getdate() there is some special cased dst adjustment logic that needs to be eliminated? ------------------------------------------------------------------------ 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