Description

mhsmith

opened on Dec 10, 2024

Issue body actions

Feature or enhancement

Proposal:

The zoneinfo module can load time zone information from the common IANA format: one directory per continent, containing one file per city. These files can come from one of two sources:

• The operating system in of the following paths: /usr/share/zoneinfo:/usr/lib/zoneinfo:/usr/share/lib/zoneinfo:/etc/zoneinfo.
• The tzdata package on PyPI.

None of the well-known paths exist on Android, so the best approach on Android is currently the same as on Windows – use the tzdata package from PyPI.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Reacted by Aaron

Activity

1. mhsmith

   added

   type-featureA feature request or enhancementA feature request or enhancement

   OS-android

   on Dec 10, 2024
2. mhsmith commented on Dec 10, 2024

   

   mhsmith

   on Dec 10, 2024

   MemberAuthor

   More actions

   I got the following message from Almaz Mingaleev on the Android team:

   We do provide tzdata, but, as you noticed, in a slightly different form: there is one single
   file which has all TZif files concatenated + some indexing. Its format is not documented
   because it is an implementation detail and we don't want anyone to rely on it. But Android
   is open-source, so certain libraries / frameworks just checked how that file is read on
   the platform. It didn't go well for Mono when we switched from fat to slim TZif
   format: mono/mono#21682. I am not particularly happy about
   their fix, but they seem to be fine with silently returning wrong data to users in their APIs.

   The overall problem is that TZif files are used as-if its format is an API, but

   1. we as a platform can't be sure that all other implementations are reading TZif files correctly.
      And when they don't it might be tricky to track down the root cause.
   2. There is a RFC for TZif, but it's outside of our control and it can go against
      library / framework maintainers' assumptions. For example, Java's java.util.TimeZone
      assumes that DST offset is zero or positive. But in the vanguard form of Europe/Dublin
      offset is negative (and there are a bunch of time zones where DST offset changed from
      negative to zero and to positive). So we, ICU, and Java are using rearguard form
      because it definitely might break someone's code.

   So thank you for not reading Android's TZif files directly! We only provide APIs: libc, Java, and ICU.

   On the subject of the ICU API, these notes in PEP 615 may be relevant.

   Reacted by Aaron and John
3. StanFromIreland

   added this to Date and time issues 🕰️on Jul 7, 2025
4. StanFromIreland

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   on Jul 8, 2025
5. pganssle commented on Sep 18, 2025

   

   pganssle

   on Sep 18, 2025

   Member

   More actions

   If the official APIs provided by android provide at least as much information as a TZif file, we can implement support for it, otherwise I think we need to rely on the tzdata package. IIRC the main problem with the Windows API was that you couldn't just get a list of transitions, you had to give it a time and it would tell you what time zone applied. If this is the API they are offering, I believe they suffer from the same problem.

   It may be possible to implement ZoneInfo on top of it, though. If these TimeZone objects are immutable objects that won't change if the underlying time zone data is updated during the run of the program, I think that API has enough information to implement all of the core functions.

Issue actions