[TZ] Kazakhstan/Almaty

[ildar]

Kazakhstan recently changed the timezones for most of the country. Please change accordingly. Some apps relying on your TZ infos.

[patrick-zippenfenig]

Thanks for the report. I will schedule the update for July.

[ildar]

Excuse me, you mean July this year? Is there a page on the workflow you're in that I can read?

[patrick-zippenfenig]

There are instructions on the readme, but I expect larger work in the upstream databases is required to update it. I do not have time in the next weeks to start working on it

[papjul]

As mentioned in breezy-weather/breezy-weather#1038 in a later message, updating the database would change nothing because GeoNames also uses Asia/Almaty.

Either GeoNames is not up-to-date or timezone name was preserved and your timezone database on your system is not up-to-date. I think the second option is more likely. On an Android system >= 10, you should get automatic updates according to docs: https://source.android.com/docs/core/permissions/timezone-rules?hl=en#timezone-apex

[ildar]

Asia/Almaty is the subject of this issue, it is one of the Kazakhstan cities that have TZ changed. So when Almaty time is changed, everyone (me at least) will be happy

[patrick-zippenfenig]

Ah, ok. Timezone updates should be more timely, but I rely on https://github.com/evansiroky/timezone-boundary-builder which is then redistributed for Open-Meteo here: https://github.com/patrick-zippenfenig/SwiftTimeZoneLookup.

[papjul]

Yes, timezones are based on boundaries, we don't update each city manually.

After looking at tzdata source code, I'm now convinced the issue is neither on GeoNames or Open-Meteo side.

As you can see in this commit: https://github.com/eggert/tz/commit/95a16c87f21c4643055482429dad921357a630c9

It is scheduled for Asia/Almaty to switch to UTC+5 starting from March 1st.

This update was released in tzdata v2024a, on 2024-02-01. An up-to-date device will have no issue. If it already is, please contact your manufacturer to let them know about the issue.

[patrick-zippenfenig]

tzdata 2024a is already installed on Open-Meteo API servers. If timezone handling is done on the client, the client also needs the correct timezone database.

The API return the correct timezone name and offset: https://api.open-meteo.com/v1/forecast?latitude=48&longitude=68&hourly=temperature_2m&timezone=auto

{"latitude":48.0,"longitude":68.0,"utc_offset_seconds":18000,"timezone":"Asia/Almaty","timezone_abbreviation":"+05"}

[papjul]

We don't use offset, we use the timezone name, because that's how it works with other weather sources we use, and it handles DST and other particularities just fine.

However, if the system on which the client is installed has an outdated timezone database, the time will also be displayed outdated.

[ildar]

I see now. I'm sorry this issue seems to be invalid. As Patrick shows, OM returns right TZ infos (GMT+5) so no problem on OM's side. Sorry for the noise.

[papjul]

Yes, sorry for telling you to report it here, I had not fully grasped what your country timezone change was about. I think it can be closed ;)