1863868 - Timezone database in calendar settings has wrong information about argentina, maybe other regions too

Status: UNCONFIRMED

(Calendar :: General, defect)

Description

[david.wells.1977]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0

Steps to reproduce:

I am running a profile created on linux with mozilla thunderbird 91.5.1 and had the setting in "Settings -> Calendar -> Use system timezone". On the host os the hardware clock is set to localtime and the time zone is "America/Argentina/Buenos_Aires". After upgrading to supernova my calendar events stopped being synchronized (I use TBSync whith the provider for exchange activesync). Inspecting the error I tried switching from "Use system timezone" to "Set timezone manually" and couldnt't find the IANA defined timezone, however I did find the America/Buenos_Aires timezone but this timezone isn't compatible with my activesync server which knows nothing of this timezone but does know about the proper America/Argentina/Buenos_Aires timezone.

I checked on thunderbird supernova for windows and found the exact same problem with the timezone definitions so it's not exlusive of linux installations.

I found that Buenos Aires isn't the only timezone with problems, Catamarca, ComodoroRivadavia (this one in particular isn't even listed as America/ComodoroRivadavia), Cordoba, Jujuy and Mendoza have the same problem

Actual results:

I couldn't use the "Use system timezone" and the manually set timezone doesn't match the IANA defined timezones

Expected results:

Having the system timezone set to "America/Argentina/Buenos_Aires" and using the "Use system timezone" should allow for the proper synchronization of calendar events on an activesync server

Comment 1

[Magnus Melin [:mkmelin] (away until Aug 10)]

Thunderbird 91.5.1 is anchient.
Thunderbird 115 uses the icu timezones.

Comment 2

[david.wells.1977]

I mentioned Thunderbird 91.5.1 for two reasons, context as to how the profile was created and because in versions prior to supernova I didn't have this problem.
I'm not familiar with icu timezones since it seems to be a programming api plus a new format for the timezone information but in the documentation it clearly states in the timezone class specification "A programmatic ID, for example, “America/Los_Angeles”. This ID is used to call up a specific real-world time zone. It corresponds to the IDs defined in the IANA Time Zone database used by UNIX and other systems, and has the format continent/city or ocean/city.". According to the information I provided the timezones displayed as options in thunderbird supernova do not correspond to the IDs defined in the IANA time zone database which clearly states that the timezone ID for Buenos Aires is America/Argentina/Buenos_Aires.

Comment 3

[Sean Burke [:leftmostcat]]

If you open Thunderbird, press Ctrl+Alt+I, and enter into the resulting console Intl.DateTimeFormat().resolvedOptions(), what's the value shown for time zone? If you're familiar with the developer tools, are you able to inspect any of the traffic with ActiveSync to see if America/Buenos_Aires is being sent as part of the request?

Technical discussion

I believe that America/Buenos_Aires showing in the listing is an unfortunate side effect of how ICU chooses what the "canonical" ID for a time zone is, which—contrary to the quote above—does not match IANA's preferred ID. For the system time zone listing, we may be able to get ICU to give us a better value for these names, but it will either require that we get API added to enumerate IANA's canonical names instead of CLDR's, or that we preload time zones in order to call getIanaID(), which would add a fair amount of overhead at startup.

Comment 4

[rapettif]

(In reply to Sean Burke [:leftmostcat] from comment #3)

If you open Thunderbird, press Ctrl+Alt+I, and enter into the resulting console Intl.DateTimeFormat().resolvedOptions(), what's the value shown for time zone? If you're familiar with the developer tools, are you able to inspect any of the traffic with ActiveSync to see if America/Buenos_Aires is being sent as part of the request?

Technical discussion

I believe that America/Buenos_Aires showing in the listing is an unfortunate side effect of how ICU chooses what the "canonical" ID for a time zone is, which—contrary to the quote above—does not match IANA's preferred ID. For the system time zone listing, we may be able to get ICU to give us a better value for these names, but it will either require that we get API added to enumerate IANA's canonical names instead of CLDR's, or that we preload time zones in order to call getIanaID(), which would add a fair amount of overhead at startup.

Hi,
I just tried to do that. I'm from Buenos Aires too. The result form the debug console is this:

11:52:40.560 Intl.DateTimeFormat().resolvedOptions()
11:52:40.600
Object { locale: "es-AR", calendar: "gregory", numberingSystem: "latn", timeZone: "America/Argentina/Buenos_Aires", year: "numeric", month: "numeric", day: "numeric" }

Regards