php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #80084 Incorrect UTC offset per Olson TZ Database in Asia/Almaty.
Submitted: 2020-09-10 18:04 UTC Modified: 2020-09-14 15:43 UTC
From: kevin at arcpointgroup dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 7.3.22 OS: Ubuntu 18.04.2 LTS
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: kevin at arcpointgroup dot com
New email:
PHP Version: OS:

 

 [2020-09-10 18:04 UTC] 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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-09-10 18:29 UTC] derick@php.net
-Status: Open +Status: Not a bug
 [2020-09-10 18:29 UTC] 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:47 UTC] 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:50 UTC] 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-11 08:52 UTC] derick@php.net
"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,
 [2020-09-14 15:43 UTC] kevin at arcpointgroup dot com
You're right. I misread that API return. I think the "issue" I'm having is that the timezone the user is using is simply the wrong one, but that's another problem altogether.

I'm sorry for wasting your time; thank you for your assistance however!
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Dec 02 17:01:35 2024 UTC