On Oct 9, 2023, at 5:45 PM, Fabrício Rennó <fabricio.renno@sxte.com.br> wrote:

These are the reasons for my suggestion being sent: - I noticed many samples with "area/country/location" (ex.: America/Argentina/...) and I believe this is a better approach;

The *only* examples of area/country/location are in Argentina. Paul, why is Argentina a special case here? The only *other* examples of area/anything/location are some cities in the United States where the *state's* name is used, i.e. area/state/location. The paragraph in the theory document: https://data.iana.org/time-zones/theory.html that describes the typical two-component format for names, and explains at least some of those relatively-rate three-component exceptions to that in the last sentence, is: Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. North and South America share the same area, 'America'. Typical names are 'Africa/Cairo', 'America/New_York', and 'Pacific/Honolulu'. Some names are further qualified to help avoid confusion; for example, 'America/Indiana/Petersburg' distinguishes Petersburg, Indiana from other Petersburgs in America.

- I noticed many Brazilian places listed as time zones, but in fact those are just local times.

As I understand, a time zone is a geographic slice that includes hundreds/thousands of places.

It is extremely important to read the initial section of the theory document I mentioned above before making any assumptions about what a IANA database "timezone" is. That section says: The tz database attempts to record the history and predicted future of civil time scales. It organizes time zone and daylight saving time data by partitioning the world into timezones whose clocks all agree about timestamps that occur after the POSIX Epoch (1970-01-01 00:00:00 UTC). Although 1970 is a somewhat-arbitrary cutoff, there are significant challenges to moving the cutoff earlier even by a decade or two, due to the wide variety of local practices before computer timekeeping became prevalent. Most timezones correspond to a notable location and the database records all known clock transitions for that location; some timezones correspond instead to a fixed UTC offset. Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time (DST), and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970. Clock transitions before 1970 are recorded for location-based timezones, because most systems support timestamps before 1970 and could misbehave if data entries were omitted for pre-1970 transitions. However, the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping. Although some information outside the scope of the database is collected in a file backzone that is distributed along with the database proper, this file is less reliable and does not necessarily follow database guidelines. As described below, reference source code for using the tz database is also available. The tz code is upwards compatible with POSIX, an international standard for UNIX-like systems. As of this writing, the current edition of POSIX is: The Open Group Base Specifications Issue 7, IEEE Std 1003.1-2017, 2018 Edition. Because the database's scope encompasses real-world changes to civil timekeeping, its model for describing time is more complex than the standard and daylight saving times supported by POSIX. A tz timezone corresponds to a ruleset that can have more than two changes per year, these changes need not merely flip back and forth between two alternatives, and the rules themselves can change at times. Whether and when a timezone changes its clock, and even the timezone's notional base offset from UTC, are variable. It does not always make sense to talk about a timezone's "base offset", which is not necessarily a single number. That says "Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time." So, while both a "traditional time zone" and an IANA database "timezone" can include hundreds or thousands of places, an IANA database "timezone" cn be smaller than a "traditional time zone". For example, there is a time zone called the Mountain Time Zone, which includes territory in the United States, Canada, and Mexico: https://en.wikipedia.org/wiki/Mountain_Time_Zone with an offset from UTC of −07:00. Two of the states in the United States that are in the Mountain Time Zone are Colorado and Arizona. However, those two states are *NOT* in the same IANA database timezone, because Colorado observes Daylight Saving Time and Arizona does not, which means that, while Daylight Saving Time is in effect, the clocks in Colorado and Arizona do *not* agree! In other words, a region that includes both Colorado and Arizona is *NOT* a region in which the clocks "all agree after 1970", so there *cannot* be a single IANA database timezone that includes both of those states. Therefore, there is an IANA database timezone named America/Denver, which covers most of the places in the United States Mountain Time Zone, and another timezone named America/Phoenix, which covers most of Arizona. (The Navajo Nation: https://en.wikipedia.org/wiki/Navajo_Nation occupies portions of the states of Arizona, New Mexico, and Utah, and *does* observe Daylight Saving Time; it is in the America/Denver IANA database timezone, not in the America/Phoenix IANA database timezone.)

So, each country does choose its official time zones

Each country is welcome to do so. The United States, for example, established several official time zones. It *also* allows individual states to choose whether to observer Daylight Saving Time or not. Arizona chose not to, while the other states in the Mountain Time Zone chose to do so. This means that not all states in the Mountain Time Zone have their clocks keeping the same time.

and for those time zones they set a special "label" for organizational purpose.

They are perfectly welcome to do so. And we are welcome to choose our own labels for IANA database timezone, which, as noted, are *not* guaranteed to correspond to particular official time zones.

As I've mentioned in my initial e-mail, Brazil officially has 4 time zones (-2, -3, -4, -5), therefore for anything time/schedule related in Brazil a person should opt among only those 4 time zones options.

Would you say that, for example, for somebody running on a Linux system, getting the correct local time that a file was last modified by typing "ls -l --full-time {file name}" is "time/schedule related"? If so, then, at least if the last time the file was modified is sufficiently far in the past, then for at least one thing time-related in Brazil a person needs to choose more than just the official time zone. And as for scheduling, well, *for now* Brazil is safe, because it no longer observes Daylight Saving Time; however, when it did, different regions in the same official time zone did not necessarily always have the same Daylight Saving Time rules. For example, the source has: # # Bahia (BA) # There are too many Salvadors elsewhere, so use America/Bahia instead # of America/Salvador. Zone America/Bahia -2:34:04 - LMT 1914 -3:00 Brazil -03/-02 2003 Sep 24 -3:00 - -03 2011 Oct 16 -3:00 Brazil -03/-02 2012 Oct 21 -3:00 - -03 # # Goiás (GO), Distrito Federal (DF), Minas Gerais (MG), # Espírito Santo (ES), Rio de Janeiro (RJ), São Paulo (SP), Paraná (PR), # Santa Catarina (SC), Rio Grande do Sul (RS) Zone America/Sao_Paulo -3:06:28 - LMT 1914 -3:00 Brazil -03/-02 1963 Oct 23 0:00 -3:00 1:00 -02 1964 -3:00 Brazil -03/-02 so America/Sao_Paulo follows the standard Brazilian rules for Daylight Savings time from 1965 to now, but America/Bahia did not follow those rules from 2011-10-16 to 2012-10-21, at which point it stopped observing Daylight Saving Time. The standard Brazilian rules, from 2008 to the present (I've omitted the pre-2010 rules), are # Rule NAME FROM TO - IN ON AT SAVE LETTER/S ... # From Frederico A. C. Neves (2008-09-10): # According to this decree # http://www.planalto.gov.br/ccivil_03/_Ato2007-2010/2008/Decreto/D6558.htm # [t]he DST period in Brazil now on will be from the 3rd Oct Sunday to the # 3rd Feb Sunday. There is an exception on the return date when this is # the Carnival Sunday then the return date will be the next Sunday... Rule Brazil 2008 2017 - Oct Sun>=15 0:00 1:00 - Rule Brazil 2008 2011 - Feb Sun>=15 0:00 0 - # Decree 7,584 <http://pcdsh01.on.br/HVdecreto7584_20111013.jpg> (2011-10-13) # added Bahia. Rule Brazil 2012 only - Feb Sun>=22 0:00 0 - # Decree 7,826 <http://pcdsh01.on.br/HVdecreto7826_20121015.jpg> (2012-10-15) # removed Bahia and added Tocantins. # Decree 8,112 <http://pcdsh01.on.br/HVdecreto8112_20130930.JPG> (2013-09-30) # removed Tocantins. Rule Brazil 2013 2014 - Feb Sun>=15 0:00 0 - Rule Brazil 2015 only - Feb Sun>=22 0:00 0 - Rule Brazil 2016 2019 - Feb Sun>=15 0:00 0 - Rule Brazil 2018 only - Nov Sun>=1 0:00 1:00 - So it appears that, in the America/Sao_Paulo IMDB database timezone, starting in October 2008, Daylight Saving Time was in effect: 2008-10-19 to 2009-02-15; 2009-10-18 to 2010-02-21; 2010-10-17 to 2011-02-20; 2011-10-16 to 2012-02-26; 2012-10-21 to 2013-02-17; 2013-10-20 to 2014-02-16; 2014-10-19 to 2015-02-22; 2015-10-18 to 2016-02-21; 2016-10-16 to 2017-02-19; 2017-10-15 to 2018-02-18; 2018-11-03 to 2019-02-17; and was never in effect after that. However, in the America/Bahia IANA database timezone, starting in October 2008, Daylight Saving Time was in effect: 2008-10-19 to 2009-02-15; 2009-10-18 to 2010-02-21; 2010-10-17 to 2011-02-20; 2012-10-21 to 2013-02-17; and was never in effect after that. So, during the time periods: 2011-10-16 to 2012-02-26; 2013-10-20 to 2014-02-16; 2014-10-19 to 2015-02-22; 2015-10-18 to 2016-02-21; 2016-10-16 to 2017-02-19; 2017-10-15 to 2018-02-18; 2018-11-03 to 2019-02-17; the clocks in the locations in the America/Bahia IANA database timezone differed from the clocks in the locations in the America/Sao_Paulo IMDB database timezone by one hour, but were the same outside of those time periods. So, during those time periods, if people in the UTC-03:00 official time zone wanted time to be processed correctly on many systems, they would have to, at minimum, choose between America/Sao_Paulo and America/Bahia. (I will let somebody else determine whether they would also need to choose, at least for times from 1970-01-01 00:00:00 UTC, among America/Belem, America/Santarem, America/Fortaleza, America/Recife, America/Araguaina, and America/Maceio as well.)

If a specific region (city, state) chooses to change its time zone reference, this should not affect the time zone itself. Time zone is not local time.

Official time zones do not determine local time, as local time is often adjusted from the standard time offset for various reasons, such as Daylight Saving Time. (There are other reasons; Morocco, for example, adjusts its clocks during Ramadan.)

I see that choices were made that generated the current database.

Yes. Given that, when the tzdb project was initiated in 1986 or so: the people who first discussed it, as I remember - Mary Horton of Bell Labs and Arthur David Olson of the US National Institutes of Health National Cancer Institute - were working on UN*X systems; UN*X systems, since some point in the early 1970s, kept track of time as a count of seconds since January 1, 1970, 00:00:00 UT C; this meant that, to display such a time stamp as local time, the offset from UTC that was in effect at that location *at that time* had to be known (the official offset from UTC for the official time zone that location is in is *NOT* sufficient, as clocks may have a different offset due to, for example, Daylight Saving Time); UN*X systems tended to compute that by having one or more fixed tables, compiled into a system library; and, to quote https://en.wikipedia.org/wiki/History_of_time_in_the_United_States#DST_1966 "On July 8, 1986, President Ronald Reagan signed the Federal Fire Prevention and Control Act of 1986 into law that contained a daylight saving rider authored by Senator Slade Gorton (R-WA). The starting date of DST was amended to the first Sunday in April effective in 1987. DST continued to end on the last Sunday in October." There had already been times in the past when that table needed to be changed, due to US time zone changes, but there were relatively few UNIX systems then, and changing the source and recompiling the C library *and* all programs using it wasn't *too* much of a burden. By 1986, however, the commercial UN*X market was significant, and the burden of doing that would be greater. Furthermore, the code from AT&T had only *one* table of Daylight Savings Time rules, meaning that if you weren't following the same Daylight Savings Time as the US, you would have to change the table and do all that recompiling. 4.2BSD UNIX from Berkeley had added a mechanism by which a small integer value could be set to indicate which rules to use, and the library had multiple such tables compiled in, but that still had compiled-in tables, and to add a new set of rules would, again, involve assigning a new integer value to the new rules, adding a table for that value, and, again, recompiling. So Horton and Olson came up with the tzdb scheme (I don't have a copy of the discussion, so I don't know how much is due to Olson and how much is due to Horton). The requirement to support the UN*X time conversion mechanisms made it an *absolute requirement* to handle times dating back at least some amount in the past, and to handle local daylight savings time rules. *That's* why the decision was made not to have "timezones" not just be "official time zones" in the sense of "what's the standard offset from UTC?", but to include Daylight Saving Time rule for the "timezone". (This, by the way, is why I prefer to call IANA database timezones "tzdb regions" - to avoid

Perhaps somewhere on the way of the IANA historical evaluation should have considered the possibility of two branches (official time zones; relevant places local times) or even other detailed lists, instead of just a single list.

Or perhaps they realized that a list of "official time zones", if that means a table only of standard offset from UTC for various "official time zones", would not ever be capable of supporting UN*X time conversion functions such as localtime() and, quite frankly, didn't see the point of making the extra effort to maintain such a list. Either that, or, given its insufficiency for localtime(), it never even occurred to them in the first place. They also didn't create any list of "relevant places local times". For example, America/Los_Angeles doesn't represent "the local time in Los Angeles and only in Los Angeles", the name of the city being in the name notwithstanding. As the theory document says: Names normally have the form AREA/LOCATION, where AREA is a continent or ocean, and LOCATION is a specific location within the area. "LOCATION" doesn't mean "every location has its own timezone", it means "for a given timezone, a specific location is chosen for the name". The location is typically a city, as per * Keep locations compact. Use cities or small islands, not countries or regions, so that any future changes do not split individual locations into different timezones. E.g., prefer Europe/Paris to Europe/France, since France has had multiple time zones. in the theory document, and is typically the most populous location within the region, as per * Use the most populous among locations in a region, e.g., prefer Asia/Shanghai to Asia/Beijing. Among locations with similar populations, pick the best-known location, e.g., prefer Europe/Rome to Europe/Milan. in the theory document. (Yes, location populations change, so what was the most populous location at the time the timezone was created will not necessarily remain the most populous location, but, to avoid disruption, the timezone name is not changed.)

If it's kept the decision to go only by cities/places this list certainly will take an avoidable

No, it's not at all "avoidable", for the reasons I've explained in detail above. (Tl;dr - if you break localtime() people will come after you with pitchforks and torches.)

large amount of energy over the years (data travelling www, resources awaiting)

Do you have any data to support your assertion that have a database that includes Daylight Saving Time rules, and distinguishes between regions with different rules, would require a large amount of additional energy over having a database that just says "here's the standard offset from UTC, good luck if that date was during Daylight Saving Time in your location"?

for nothing so relevant, unfortunately.

It may be unfortunate that various parts of the world chose to observe Daylight Saving Time, requiring all this extra information, and that people in regions that don't currently observe Daylight Saving Time but did so in the past might need to or want to convert seconds-since-1970-01-01T00:00:00UTC time stamps in the past to local time, but it's the reality, so all the Daylight Saving Time rules are, in fact, relevant.

On Oct 10, 2023, at 1:59 PM, Fabrício Rennó <fabricio.renno@sxte.com.br> wrote:

I think I made my idea clear about the need of a lighter approach.

As Paul indicated, a simpler *IANA database timezone selector* might be useful. Cutting back on IANA database timezones, however, won't work, for all the reasons indicated. The *best* timezone selector, from a user's perspective, is *no* timezone selector. The machine on which I'm typing this has a mechanism (Location Services) that allows it to determine, in many cases, an approximate longitude and latitude (even without access to global positioning satellites or a mobile phone network, neither of which it has), and uses that plus, presumably, a set of maps of the IANA database timezones, to select the appropriate timezone, and switches the system to that timezone as necessary. (Yes, this means that if I travel from one IANA database timezone to another, the current timezone changes automatically. For example, if I traveled to Colorado, and then to Arizona, and then back to California, the timezone would change three times. And, yes, that would even change out from under a program such as #include <stdio.h> #include <time.h> #include <unistd.h> int main(void) { time_t now; for (;;) { now = time(NULL); printf("%s", ctime(&now)); sleep(5); } } would shift the time to local time after all three of those travels.) The second-best, from a user's perspective, is something that lets you indicate the name of a nearby city, from a reasonably large list of cities, or just type in the name of a city, and choose based on that. Anything that involves selecting from a list of IANA database timezone names is inferior to that.

On 10/9/23 23:25, Guy Harris via tz wrote:

On Oct 9, 2023, at 5:45 PM, Fabrício Rennó <fabricio.renno@sxte.com.br> wrote:

...

These are the reasons for my suggestion being sent: - I noticed many samples with "area/country/location" (ex.: America/Argentina/...) and I believe this is a better approach;

The *only* examples of area/country/location are in Argentina. Paul, why is Argentina a special case here?

The idea was the same as for America/Indiana/Petersburg. We have that name because America/Petersburg would likely be confused with Petersburg, Virginia. We have America/Argentina/San_Juan because America/San_Juan would likely be confused with San Juan, Puerto Rico. There was no similar confusion for Brazilian locations so there was no need to create a subdirectory for Brazil.

Thank you Paul. I hope the future reviews on this can create simplified structures for us all. Regards, Fabrício Rennó +55 31 98648-8987 (mobile) +55 31 3643-1014 (office) www.sxte.com.br www.aico.com.br (conheça) -----Mensagem original----- De: Paul Eggert <eggert@cs.ucla.edu> Enviada em: terça-feira, 10 de outubro de 2023 17:51 Para: Fabrício Rennó <fabricio.renno@sxte.com.br> Cc: Time Zone Mailing List <tz@iana.org> Assunto: Re: [tz] RES: Timezone for Brazil [Geralmente, você não obtém emails de eggert@cs.ucla.edu. Saiba por que isso é importante em https://aka.ms/LearnAboutSenderIdentification ] On 10/9/23 17:45, Fabrício Rennó via tz wrote:

As I've mentioned in my initial e-mail, Brazil officially has 4 time zones (-2, -3, -4, -5), therefore for anything time/schedule related in Brazil a person should opt among only those 4 time zones options.

On my long list of things to do is coming up with a table that would let users do that more easily. It would be like tzdb's current zone1970.tab, which partitions the world into zones where clocks have agreed since 1970; however, it would partition the world into a smaller set of larger zones whose clocks agree now and are predicted to agree in the future. This would be something along thne lines as you suggested, as people in Brazil would have just four zones to chose from in this new table.

Perhaps somewhere on the way of the IANA historical evaluation should have considered the possibility of two branches (official time zones; relevant places local times) or even other detailed lists, instead of just a single list.

We already have two such lists (zone1970.tab and zone.tab), and a new file (zonenow.tab, say) could be a third list that would work as described above.

On 2023-10-11 13:27, Doug Ewell via tz wrote:

Fabrício Rennó wrote:

...

I think I made my idea clear about the need of a lighter approach.

*Your desire* for a lighter approach.

...

...

On my long list of things to do is coming up with a table that would let users do that more easily. It would be like tzdb's current zone1970.tab, which partitions the world into zones where clocks have agreed since 1970; however, it would partition the world into a smaller set of larger zones whose clocks agree now and are predicted to agree in the future. This would be something along thne lines as you suggested, as people in Brazil would have just four zones to chose from in this new table. I hope the future reviews on this can create simplified structures for us all. For *some* with very simple and less stringent requirements; others including astrologers, astronomers, historians, physicists, space mission planners, travel industries, and international systems and software developers and engineers, may all have more stringent requirements than your limited local desires.

It would be the same as telling you that your design programs need only data for the most common forms and sizes of common structural materials: standard concrete, steels, and some woods, beams and columns, and nothing more; or maybe as it is so limited, that you could do all your design with only those materials, using only a spreadsheet of constants, one of conversion factors, another of dimensions, a couple for working calculations, and that's all you get.

To be clear, any “lighter approach” or “simplified structures” will most likely take the form of an additional file, as Paul described below. It will almost certainly not involve removing any timezones (or “tzdb regions”) from the database. What is deployed will depend greatly on the downstream user community and distro or downstream package maintainers. For maximal compatibility and usefulness for all, many will keep all history available, possibly in rearguard format, as with Oracle Java, unless they have deprecated or dropped their old structures, and moved to newer libraries.

-- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

On Oct 10, 2023, at 2:23 PM, Doug Ewell via tz <tz@iana.org> wrote:

This would be very helpful for applications like ours, which asks users to select a time zone which is then transmitted to an external device that requires a tzid. Thanks to CLDR, the user gets to choose a human-readable name instead of a raw tzid, but still has to choose from among many time zones with the same base offset.

Are they being requested to select their *own* timezone or to select some *other* timezone? If it's their own timezone, can your application query the system to determine it?

Remember that most users are not as knowledgeable about time zones as we are. In an informal poll of co-workers about the list of ~425 zones, some thought they should pick the zone corresponding to the city physically closest to them, e.g. America/Detroit in preference to America/New_York.

Most users should never be exposed to the existence of "America/Detroit" or "America/New_York" or "America/Sao_Paolo" or "America/Noronha" or "Asia/Shanghai" or "Europe/Berlin" or.... But presumably the list of cities is *not* just the list of cities used as LOCATIONs in tzdb IDs, so they can choose a city that's *neither* Detroit *nor* New York. (In macOS, I can choose the city in which I live, although, alas, I can't choose Weed.)

On Oct 10, 2023, at 3:48 PM, Doug Ewell <doug@ewellic.org> wrote:

Guy Harris wrote:

...

Most users should never be exposed to the existence of "America/Detroit" or "America/New_York" or "America/Sao_Paolo" or "America/Noronha" or "Asia/Shanghai" or "Europe/Berlin" or....

As I know I said at least twice, the app does not display raw tzids, but instead strings returned by CLDR (actually ICU, and with a UTC base offset prepended as requested by marketing):

(UTC-05:00) Eastern Time (Detroit) (UTC-05:00) Eastern Time (New York) (UTC-03:00) Brasilia Standard Time (Sao Paulo) etc.

Users ideally shouldn't be exposed to the tzdb maintainers' choices of LOCATIONs at all. "Los Angeles" isn't much better than "America/Los_Angeles", especially for people not in the LA area. (As far as I know, we haven't gotten complaints about LA vs. San Francisco or LA vs. San Jose or LA vs. San Diego, but we *have* gotten at least one complaint about Asia/Beijing not working, which is why I mentioned Asia/Shanghai.) And, depending on the locale, there might be ways of choosing between different timezones that cover the same time zone, e.g. (UTC-7:00) Mountain Time (most locations) (UTC-7:00) Mountain Time (Arizona) (with whatever tweaks would be most straightforward to include the Navajo Nation and the Hopi Nation) that might be more obvious than (UTC-7:00) Mountain Time (Denver) (UTC-7:00) Mountain Time (Phoenix) ("But I'm in Boulder!" "And I'm in Tempe!" "And *I'm* in Jackson Hole!").

Brasilia “Standard” Time is not ideal, but it’s what ICU gives us,

The ICU appears to have, at least in common/main/en.xm: <metazone type="Brasilia"> <long> <generic>Brasilia Time</generic> <standard>Brasilia Standard Time</standard> <daylight>Brasilia Summer Time</daylight> </long> </metazone> Not sure how you'd ask for "generic" rather than "standard" or "daylight" or, if you're already doing that, why it's not coughing up "Brasilia Time".

...

(In macOS, I can choose the city in which I live, although, alas, I can't choose Weed.)

Weed, geonameid 5573449, is very much available in the GeoNames database, including its ‘cities1000’ data which includes only populated places (not other geographic features) that either have a population of 1,000 or greater or are an administrative seat.

But Apple didn't include it. Deborah? :-) (Yes, I'm just asking because I like the name.) (BTW, the hatnote on the Wikipedia article for Weed, California is a bit amusing.)

On Oct 10, 2023, at 4:48 PM, Doug Ewell <doug@ewellic.org> wrote:

This is what we get from a known, reliable source that offers human-readable names in English (or, importantly, 140 other languages) corresponding to tzids. Some of the names are probably not perfect for a picker. We already know that “(other)” and “(most locations)” are not always perfect either, especially when presented out of context: Other than what? What does “most” include?

Perhaps it's time for somebody to run some UI experiments to determine what works best for what groups of users. (Complaints that you live in city X but the selector only offers city Y count against "works best".)

We’re using a standard .NET Core call that queries ICU in a Linux container, and makes a Windows call when running on Windows. There are no options to select names for standard, daylight, or generic, and I don’t know why it chooses standard by default. The ICU folks might know.

I'm guessing it's easier for .NET languages to use ICU4C than ICU4J; the icu::TimeZone Class Reference: https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1Tim... appears to offer several flavors of the getDisplayName method, with: UnicodeString &getDisplayName(UBool inDaylight, EDisplayType style, UnicodeString &result) const and UnicodeString &getDisplayName(UBool inDaylight, EDisplayType style, const Locale &locale, UnicodeString &result) const having the style argument, which is an EDisplayType: https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1Tim... I'm guessing that SHORT and LONG use the inDaylight value to determine whether to provide the short or long standard time or the short or long daylight time name, and SHORT_GENERIC and LONG_GENERIC provide the short or long generic name. At least from what I see on Microsoft Learn, the .NET 7.0 TimeZone class: https://learn.microsoft.com/en-us/dotnet/api/system.timezone?view=net-7.0 only has the standard and daylight names as properties However, the .NET 7.0 TimeZoneInfo class: https://learn.microsoft.com/en-us/dotnet/api/system.timezoneinfo?view=net-7.... also has the DisplayName property, which "Gets the general display name that represents the time zone", and might provide the generic name when it's using ICU.

Re-reading the thread, it seems part of the question is why the word "Standard" is present in "(UTC-03:00) Brasilia Standard Time (Sao Paulo)". That's due to the 184 day rule, specified in the "TypeFallback" section of the TR35 spec that ICU uses to interpret CLDR data. See https://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names .NET tries to side-step that, in the FixupTimeZoneGenericDisplayName function here: https://github.com/dotnet/runtime/blob/f20509b9ea563da18af963976b7db0e523e68... Unfortunately, the fixup function only works if there's at least one zone in the same metazone whose generic name doesn't get the 184 day rule applied. So it can make all zones that have a generic name of "Mountain Standard Time" use the name "Mountain Time" instead (thanks to America/Phoenix), but it can't find any alternative to "Brasilia Standard Time" because all the zones in "Brasilia" metazone all have the same generic name, "Brasilia Standard Time". (Note, one can't simply remove words from the string, because you'd have to account for the equivalent of "Standard" in every supported language). Metazones are in CLDR here: https://github.com/unicode-org/cldr/blob/main/common/supplemental/metaZones.... And here's the language entry for English for the Brasilia metazone: https://github.com/unicode-org/cldr/blob/657e6e996b88b891132db29cc4fc61c36f1... <metazone type="Brasilia"> <long> <generic>Brasilia Time</generic> <standard>Brasilia Standard Time</standard> <daylight>Brasilia Summer Time</daylight> </long> </metazone> So, you get "Brasilia Standard Time" because according to ICU, that is the generic name for the Brasilia metazone, even though CLDR has "Brasilia Time" - the 184 day rule applies and ICU overrides it with the standard name. Unfortunately, I have not found a way to get the generic name directly from ICU4C (via a C API, not C++), that doesn't apply the 184 day rule. -Matt On Thu, Oct 12, 2023 at 9:53 AM Matt Johnson-Pint <mattjohnsonpint@gmail.com> wrote:

Hi. I contributed most of the improvements to time zone display name logic for .NET, so I can offer some clarity here. The original PR for this work is at: https://github.com/dotnet/runtime/pull/48931. There's also a detailed blog post here:

https://devblogs.microsoft.com/dotnet/date-time-and-time-zone-enhancements-i...

First off - Ignore anything related to the System.TimeZone class. That only exists for legacy reasons and is generally considered deprecated. Only System.TimeZoneInfo should be used in .NET today.

As of .NET 6, when running on Linux or MacOS, TimeZoneInfo gets its display names from ICU4C. As you suspected, it cannot leverage ICU4J. It is also limited to the C APIs. It cannot use ICU's C++ APIs.

To construct time zone display names, .NET makes calls to both ucal_getTimeZoneDisplayName, and udat_format with several different formats. You can see these ICU calls and others in the following file:

https://github.com/dotnet/runtime/blob/f20509b9ea563da18af963976b7db0e523e68...

You'll also want to look at the implementation of the GetFullValueForDisplayNameField method here:

https://github.com/dotnet/runtime/blob/f20509b9ea563da18af963976b7db0e523e68...

(git hashes are just the current values, for permalink purposes)

Between the two files, you'll notice that to use ICU alone to build a list of time zone display names is quite challenging. It's not quite as simple as just taking the LONG_GENERIC of each one. For example, if you do that, you'll find at least 13 different entries that all have the same display name, "Mountain Standard Time". While useful on a single zone, they're useless when distinguishing one zone from the next in a list. Additionally, the word "Standard" can get in the way. Ultimately one desires names like "Mountain Time (Phoenix)" vs "Mountain Time (Denver)" - so that they are disambiguated.

There are lots of other edge cases though, and some of it requires an opinionated mindset. For example, see some of the overrides here:

https://github.com/dotnet/runtime/blob/f20509b9ea563da18af963976b7db0e523e68...

Hope that helps. Feel free to ask any follow up questions.

-Matt

On Tue, Oct 10, 2023 at 5:12 PM Guy Harris via tz <tz@iana.org> wrote:

...

On Oct 10, 2023, at 4:48 PM, Doug Ewell <doug@ewellic.org> wrote:

...

This is what we get from a known, reliable source that offers human-readable names in English (or, importantly, 140 other languages) corresponding to tzids. Some of the names are probably not perfect for a picker. We already know that “(other)” and “(most locations)” are not always perfect either, especially when presented out of context: Other than what? What does “most” include?

Perhaps it's time for somebody to run some UI experiments to determine what works best for what groups of users. (Complaints that you live in city X but the selector only offers city Y count against "works best".)

...

We’re using a standard .NET Core call that queries ICU in a Linux container, and makes a Windows call when running on Windows. There are no options to select names for standard, daylight, or generic, and I don’t know why it chooses standard by default. The ICU folks might know.

I'm guessing it's easier for .NET languages to use ICU4C than ICU4J; the icu::TimeZone Class Reference:

https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1Tim...

appears to offer several flavors of the getDisplayName method, with:

UnicodeString &getDisplayName(UBool inDaylight, EDisplayType style, UnicodeString &result) const

and

UnicodeString &getDisplayName(UBool inDaylight, EDisplayType style, const Locale &locale, UnicodeString &result) const

having the style argument, which is an EDisplayType:

https://unicode-org.github.io/icu-docs/apidoc/released/icu4c/classicu_1_1Tim...

I'm guessing that SHORT and LONG use the inDaylight value to determine whether to provide the short or long standard time or the short or long daylight time name, and SHORT_GENERIC and LONG_GENERIC provide the short or long generic name.

At least from what I see on Microsoft Learn, the .NET 7.0 TimeZone class:

https://learn.microsoft.com/en-us/dotnet/api/system.timezone?view=net-7.0

only has the standard and daylight names as properties

However, the .NET 7.0 TimeZoneInfo class:

https://learn.microsoft.com/en-us/dotnet/api/system.timezoneinfo?view=net-7....

also has the DisplayName property, which "Gets the general display name that represents the time zone", and might provide the generic name when it's using ICU.

Unfortunately, ICU always uses the 184 day rule to choose the standard name when formatting generic non-location names, regardless of whether a more suitable generic name exists or not. See the implementation of the formatGenericNonLocationName function (search for usages of the kDstCheckRange constant). https://github.com/unicode-org/icu/blob/3d1dee683743c4578ced479c10b1fbe25aea... I agree - this is entirely too complicated. The fact is that currently, ICU generic names (of any form) are designed to apply in the context of having a date, time, and time zone - not for choosing a time zone from a list. Sometimes those are the same, but not always. -Matt On Fri, Oct 13, 2023 at 5:47 PM Guy Harris <gharris@sonic.net> wrote:

On Oct 12, 2023, at 10:24 AM, Matt Johnson-Pint <mattjohnsonpint@gmail.com> wrote:

...

Re-reading the thread, it seems part of the question is why the word "Standard" is present in "(UTC-03:00) Brasilia Standard Time (Sao Paulo)". That's due to the 184 day rule, specified in the "TypeFallback" section of the TR35 spec that ICU uses to interpret CLDR data. See https://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names

The only mention of 184 days I see there is:

Type Fallback

When a specified type (generic, standard, daylight) does not exist:

1. If the daylight type does not exist, then the metazone doesn’t require daylight support. For all three types: 1. If the generic type exists, use it. 2. Otherwise if the standard type exists, use it. 2. Otherwise if the generic type is needed, but not available, and the offset and daylight offset do not change within 184 day +/- interval around the exact formatted time, use the standard type. 1. Example: "Mountain Standard Time" for Phoenix 2. Note: 184 is the smallest number that is at least 6 months AND the smallest number that is more than 1/2 year (Gregorian).

2. says "if the generic type is needed, *but not available*, and a transition doesn't occur within the 184-day interval, fall back the standard type"; it doesn't appear to say "never use the generic type even if it *is* available".

I'm not sure what "not available" means in this context, but, in the tip of the main branch of https://github.com/unicode-org/cldr.git, the file common/main/en.xml has

<metazone type="America_Mountain"> <long> <generic>Mountain Time</generic> <standard>Mountain Standard Time</standard> <daylight>Mountain Daylight Time</daylight> </long> <short> <generic>MT</generic> <standard>MST</standard> <daylight>MDT</daylight> </short> </metazone>

and common/supplemental/metaZones.xml has

<timezone type="America/Phoenix"> <usesMetazone mzone="America_Mountain"/> </timezone>

so I'm not sure why they're giving Phoenix as an example of a location where the generic type is "not available".

And common/main/en.xml has

<metazone type="Brasilia"> <long> <generic>Brasilia Time</generic> <standard>Brasilia Standard Time</standard> <daylight>Brasilia Summer Time</daylight> </long> </metazone>

common/main/pt.xml has

<metazone type="Brasilia"> <long> <generic>Horário de Brasília</generic> <standard>Horário Padrão de Brasília</standard> <daylight>Horário de Verão de Brasília</daylight> </long> <short> <generic>BRT</generic> <standard>BRT</standard> <daylight>BRST</daylight> </short> </metazone>

and common/supplemental/metaZones.xml has

<timezone type="America/Sao_Paulo"> <usesMetazone mzone="Brasilia"/> </timezone>

so, at least in English and Portuguese, the common name is available for America/Sao_Paulo, at least.

Perhaps it's not as simple as "to find the generic, standard, and daylight saving time long and short names for a given tzid, find its metazone from common/supplemental/metaZones.xml and use the values there, based on the date and time if necessary", but, if so, *that* would strike me as a sign that this process is Too Complicated and that the tzdb and CLDR people should figure out something better.

("Based on the date and time if necessarily" is for handling cases where a given tzdb region goes from Eastern Freedonian Time to Central Freedonian Time or something such as that, wherein Europe/Freedoniaville would be mapped to the "Europe_Eastern_Freedonia" metazone before the transition and "Europe_Central_Freedonia" metazone at and after the transition; moves such as that are rare, but they do happen and there are instances of that in the tzdb.)

I.e., it appears that the 184 day rule is part of a *workaround* for cases in which a metazone has a "standard time" name for the time, and possibly a "daylight saving time" name for the time, but has no "generic" name for the time; it's *not* an override that causes the "generic" time never to be used.