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
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
3 + 1 = ?
Subscribe to this entry?

 
 [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

Add a Patch

Pull Requests

Add a Pull Request

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: Fri Mar 29 07:01:28 2024 UTC