Bug #80084 [Nab]: Incorrect UTC offset per Olson TZ Database in Asia/Almaty.
Edit report at https://bugs.php.net/bug.php?id=80084&edit=1
ID: 80084
Updated by: derick@php.net
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:
"dstOffset": 3600,
"rawOffset": 21600,
rawOffset is UTC+06
dstOffset adds 1, to make it UTC+07
I don't know what's wrong there? I don't have an API key so I can't check for
what for example does for London (51.5N, 0E). I expect it to say:
"dstOffset": 3600,
"rawOffset": 0,
Previous Comments:
------------------------------------------------------------------------
[2020-09-10 18:50:35] kevin at arcpointgroup dot com
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.
------------------------------------------------------------------------
[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×tamp=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
Thread (6 messages)