Bug #80084 [Com]: Incorrect UTC offset per Olson TZ Database in Asia/Almaty.

From: Date: Thu, 10 Sep 2020 18:50:35 +0000
Subject: Bug #80084 [Com]: Incorrect UTC offset per Olson TZ Database in Asia/Almaty.
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228962@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=80084&edit=1 ID: 80084 Comment by: kevin at arcpointgroup dot com Reported by: kevin at arcpointgroup dot com Summary: Incorrect UTC offset per Olson TZ Database in Asia/Almaty. Status: Not a bug Type: Bug Package: Date/time related Operating System: Ubuntu 18.04.2 LTS PHP Version: 7.3.22 Block user comment: N Private report: N New Comment: I'm sorry for not including this sooner. It is the result of the Google Timezone API lookup: { "dstOffset": 3600, "rawOffset": 21600, "status": "OK", "timeZoneId": "Asia/Almaty", "timeZoneName": "Almaty Summer Time" } Either they are providing the wrong timezone for the region, or the wrong offset for the timezone. Previous Comments: ------------------------------------------------------------------------ [2020-09-10 18:47:38] kevin at arcpointgroup dot com Thank you for your speedy assistance! I see what you mean regarding the "until" format. Notice that the Google Timezone API also confirms my original complaint, and also matches the timeofdate.com reference I linked to. In order to test, however, you need an API key, but the requests are free. Here is a request that can be POSTed for the region in question and the date specified with a valid API key: https://maps.googleapis.com/maps/api/timezone/json?location=53.219809,63.635423&timestamp=519893100&key=<your-api-key> I realize what Google says is irrelevant to PHP, but wanted to mention this for completeness. ------------------------------------------------------------------------ [2020-09-10 18:29:19] derick@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The date that you're referring to in the column is the *UNTIL* column, and refers to when then the rule ends. It shows that +05 was in place until 1930 Jun 21, which is also the data that their compiler produces: Asia/Almaty -9223372036854775808 = NULL Asia/Almaty -9223372036854689408 = NULL Asia/Almaty Thu May 1 18:52:11 1924 UT = Thu May 1 23:59:59 1924 LMT isdst=0 gmtoff=18468 Asia/Almaty Thu May 1 18:52:12 1924 UT = Thu May 1 23:52:12 1924 +05 isdst=0 gmtoff=18000 Asia/Almaty Fri Jun 20 18:59:59 1930 UT = Fri Jun 20 23:59:59 1930 +05 isdst=0 gmtoff=18000 Asia/Almaty Fri Jun 20 19:00:00 1930 UT = Sat Jun 21 01:00:00 1930 +06 isdst=0 gmtoff=21600 Asia/Almaty Tue Mar 31 17:59:59 1981 UT = Tue Mar 31 23:59:59 1981 +06 isdst=0 gmtoff=21600 Asia/Almaty Tue Mar 31 18:00:00 1981 UT = Wed Apr 1 01:00:00 1981 +07 isdst=1 gmtoff=25200 ... Asia/Almaty Sat Sep 28 20:00:00 1985 UT = Sun Sep 29 02:00:00 1985 +06 isdst=0 gmtoff=21600 Asia/Almaty Sat Mar 29 19:59:59 1986 UT = Sun Mar 30 01:59:59 1986 +06 isdst=0 gmtoff=21600 Asia/Almaty Sat Mar 29 20:00:00 1986 UT = Sun Mar 30 03:00:00 1986 +07 isdst=1 gmtoff=25200 Asia/Almaty Sat Sep 27 19:59:59 1986 UT = Sun Sep 28 02:59:59 1986 +07 isdst=1 gmtoff=25200 Asia/Almaty Sat Sep 27 20:00:00 1986 UT = Sun Sep 28 02:00:00 1986 +06 isdst=0 gmtoff=21600 Asia/Almaty Sat Mar 28 19:59:59 1987 UT = Sun Mar 29 01:59:59 1987 +06 isdst=0 gmtoff=21600 That means that this rule is in effect in 1986: 6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s That website that you refer to is wrong and likely made the same error as you did. The wikipedia page (https://en.wikipedia.org/wiki/Time_in_Kazakhstan) also has a comment about that Kostanay might not actually use the Almaty timezone. ------------------------------------------------------------------------ [2020-09-10 18:04:54] kevin at arcpointgroup dot com Description: ------------ Date Extension Settings (default for PHP 7.3): ``` date/time support enabled timelib version 2018.03 "Olson" Timezone Database Version 2020.1 Timezone Database internal Default timezone UTC ``` According to the Olson Timezone Database, the UTC offset value for timezone Asia/Almaty for 1986-06-01T00:00:00 should be either +5 or +6 hours. (If daylight savings time is observed, then the offset will be +6 hours.) PHP returns +7 hours. See the timezone rule for this timezone that has been in place for 5 years (prior to PHP 7.3): https://github.com/eggert/tz/blame/cb2d288ae0bb3aa5fb7cc94480ea955ff76bd183/asia#L2332 Here is an additional reference indicating the appropriate UTC offset for this timezone and aforementioned date should be +6 hours: http://en.timeofdate.com/city/Kazakhstan/Kostanay/timezone/change?start=1980 (Kostanay, Kazakhstan uses the Asia/Almaty timezone.) Test script: --------------- $dt = new DateTime('1986-06-01 00:00:00', new DateTimeZone('Asia/Almaty')); echo $dt->format('Z'); Expected result: ---------------- 21600 Actual result: -------------- 25200 ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=80084&edit=1

« previous php.bugs (#228962) next »