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.

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.

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.

"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,

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!