1609714 - Intl.DateTimeFormat().resolvedOptions() does not return proper timezone in Android devices

Status: RESOLVED DUPLICATE of bug 1534160

(GeckoView :: General, defect, P3)

Description

[econdepe]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Steps to reproduce:

Intl.DateTimeFormat().resolvedOptions().timeZone is expected to return a String value identifying the runtime’s default time zone. In Firefox for desktop (version 72), such a String value matches one of the timezones in the IANA tz database (https://data.iana.org/time-zones/tz-link.html#tzdb). The preferred format for that string is "Area/Location", and indeed Firefox for desktop seems to always produce such values. So for the following locations I will get the following values:

• Spain, Madrid -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Europe/Madrid'.
• Lithuania -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Europe/Vilnius'.
• North Macedonia -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Europe/Belgrade' (the timezone 'Europe/Skopje' exists in the database, but is an "alias" for 'Europe/Belgrade', which is the "canonical" one).
• Ghana -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Africa/Accra'.
• US, Denver -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'America/Denver'.
• US, Honolulu -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Pacific/Honolulu'.
• Australia, Darwin -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Australia/Darwin'.
  Now I open Firefox (versions 68, 68beta, preview 71) on different Android devices (Motorola g7, Nokia S6, Huawei), and ask again for Intl.DateTimeFormat().resolvedOptions().timeZone when changing the timezone of my device.

Actual results:

The results I get are:

• Spain, Madrid -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'CET'.
• Lithuania -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'Europe/Athens'.
• North Macedonia -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'CET'
• Ghana -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'UTC'.
• US, Denver -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'America/Denver'.
• US, Honolulu -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'HST'.
• Australia, Darwin -> Intl.DateTimeFormat().resolvedOptions().timeZone = 'UTC'.

Expected results:

I would expect the same results when using Firefox in my mobile device as the ones I get in my desktop (other browsers like Chrome seem to be indeed consistent). As can be seen from the few examples below, with respect to the "desktop timezone", the "mobile timezone":

• Sometimes it is correct (like for US, Denver).
• Sometimes it has the same offset but the name of another canonical timezone (like for Lithuania, where we get 'Europe/Athens').
• Sometimes it has the same offset, but the name of a timezone that is not in the preferred format (like for Spain, Madrid, where we get 'CET; Ghana, where we get 'UTC'; or US, Honolulu, where we get 'HST') by the tz database. Arguably we should not use such timezones anymore nowadays, and indeed they're considered as deprecated by many libraries (see e.g. https://www.php.net/manual/en/timezones.others.php).
• Sometimes it is just wrong (like for Australia, Darwin).

Comment 1

[Stefan Arentz | :st3fan | ⏰ EST | he/him]

Asking the GV team to triage this one.

Comment 2

[James Willcox (:snorp) ([e-mail]) (he/him)]

Zibi, is this expected? Do you know what might be going on here?

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

I don't think we separate what data we package for GV and desktop, so I would expect us to carry all the same timezone names.

Andre - does this look normal to you? I thought we use ICU and ICU has a decent support for Android timezones?

Comment 4

[André Bargull [:anba]]

This is a dup of bug 1534160.

:m_kato has already prepared a PR at https://github.com/unicode-org/icu/pull/605, but it looks like the latest PR updates fell through the cracks, because I don't see any further review comments resp. approvals.