Hi Marcio! "Metazone" is a CLDR term. See:http://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Names http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml CLDR depends on TZDB, but not vice-versa. You may also be interested in:https://en.wikipedia.org/wiki/Time_in_Brazil Cheers!-Matt From: silverpie2@mac.com Date: Fri, 9 Oct 2015 15:04:54 -0400 To: marcio.ikeda@lge.com CC: tz@iana.org Subject: Re: [tz] Timezone in Brazil This is one of the most common questions we get. Being the capital is not meaningful--it's the largest city in the zone that names it. Thus, Brasilia would be in the São Paulo (or Rio de Janeiro) zone. (Similarly, Washington DC is in the New York zone, and Ottawa in the Toronto zone.) Envoyé de mon iPad Le 8 oct. 2015 à 17:21, MARCIO IKEDA <marcio.ikeda@lge.com> a écrit : This is Marcio Ikeda from LG Electronics in Brazil. Nice to meet you! I would like to know if there are some background history for timezones in Brazil.It seems that Brasilia city which is the capital, is only treated as a metaZone and not a timeZone.I would like to know if are there some discussions on why America/Brasilia is not in the list.And if It is possible to include it. This is causing people from QA here to question this. Thank you! Marcio IkedaSoftware Engineer | UIFW – LGESP SCA R&D LabOffice: + 55 11 2202 5339Mobile:+ 55 11 9 9966 6457E-mail: marcio.ikeda@lge.com <image001.jpg> LG ELECTRONICS DO BRASILAv. Dr. Chucri Zaidan, 1170 – 10º andar – CEP 04583-110 – São Paulo/SPwww.lge.com/br <image002.jpg>

TZDB doesn't track display names. This is the realm of CLDR. The choice of your Android example to show the TZDB identifier directly is a function of that particular example. I'm not sure if you mean the Android OS, or an app running on Android, but either way it wouldn't matter. If it wanted to show something other than America/Sao_Paulo to the end user, it should get that information from a localization data resource - which is what CLDR is all about.http://cldr.unicode.org/ There are reasons for why the zones are named as they are. You may wish to read:http://www.iana.org/time-zones/repository/tz-link.htmlhttps://github.com/egg... If you search the tz list archive, you'll see this has been discussed many times in the past also:https://www.google.com/#q=site:http:%2F%2Fmm.icann.org%2Fpipermail%2Ftz%2F+b... From: marcio.ikeda@lge.com To: mj1856@hotmail.com; silverpie2@mac.com CC: tz@iana.org Date: Fri, 9 Oct 2015 16:05:25 -0400 Subject: RE: [tz] Timezone in Brazil Guys, Thank you for clarifications. Let me try to exemplify the problem. It is strange that in Brazil we have 4 major timezone areas: Fernando de Noronha (GMT -2) -> America/NoronhaBrasilia (GMT -3) -> America/Sao_PauloAmazonas (GMT -4) -> America/ManausAcre (GMT -5) -> America/Rio_Branco Manaus is capital of AmazonasRio Branco is capital of AcreBrasilia is capital of Brazil and in state of GoiasFernando de Noronha is an island People in Brazil, call it as “Horario de Brasilia” as the main timezone. In Windows it displays Brasilia for user.In iOS has the Brasilia entry as well.In Android (my interested area) the timezone list uses Exemplar location, so “Sao Paulo” is shown. I don`t know how other systems manages timezones. But it is sure that there is some mismatching. What do you guys think ?An entry like America/Brasilia, mapping to America/Sao_Paulo and changing displayName would be the solution ? Thanks in advance. Marcio Ikeda From: Matt Johnson [mailto:mj1856@hotmail.com] Sent: sexta-feira, 9 de outubro de 2015 16:43 To: J Andrew Lipscomb; MARCIO IKEDA/LGESP R&D GSM SW(marcio.ikeda@lge.com) Cc: tz@iana.org Subject: RE: [tz] Timezone in Brazil Hi Marcio! "Metazone" is a CLDR term. See:http://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Nameshttp://uni... CLDR depends on TZDB, but not vice-versa. You may also be interested in:https://en.wikipedia.org/wiki/Time_in_Brazil Cheers!-MattFrom: silverpie2@mac.com Date: Fri, 9 Oct 2015 15:04:54 -0400 To: marcio.ikeda@lge.com CC: tz@iana.org Subject: Re: [tz] Timezone in BrazilThis is one of the most common questions we get. Being the capital is not meaningful--it's the largest city in the zone that names it. Thus, Brasilia would be in the São Paulo (or Rio de Janeiro) zone. (Similarly, Washington DC is in the New York zone, and Ottawa in the Toronto zone.) Envoyé de mon iPad Le 8 oct. 2015 à 17:21, MARCIO IKEDA <marcio.ikeda@lge.com> a écrit :This is Marcio Ikeda from LG Electronics in Brazil. Nice to meet you! I would like to know if there are some background history for timezones in Brazil.It seems that Brasilia city which is the capital, is only treated as a metaZone and not a timeZone.I would like to know if are there some discussions on why America/Brasilia is not in the list.And if It is possible to include it. This is causing people from QA here to question this.Thank you! Marcio IkedaSoftware Engineer | UIFW – LGESP SCA R&D LabOffice: + 55 11 2202 5339Mobile:+ 55 11 9 9966 6457E-mail: marcio.ikeda@lge.com <image001.jpg> LG ELECTRONICS DO BRASILAv. Dr. Chucri Zaidan, 1170 – 10º andar – CEP 04583-110 – São Paulo/SPwww.lge.com/br <image002.jpg>

On Oct 9, 2015, at 9:22 PM, Random832 <random832@fastmail.com> wrote:

Matt Johnson <mj1856@hotmail.com> writes:

...

TZDB doesn't track display names. This is the realm of CLDR.

Since no-one ever bothers to explain *how* the CLDR does it, this is what I've been able to figure out.

The user having selected Brazil from a list of countries,

Even if you don't have a "get the location of the machine and set it based on that" option, the UI doesn't necessarily have to involve selecting a country from a list of countries. As per my other recent mail, OS X lets you shut off the "get the location of the machine and set it based on that" option; if you do that, it gives you a map that you can click on, in addition to a combo box from which you can select a city (the list of cities is based on the location you've clicked on in the map) or type in an arbitrary city. The drop-down list in the combo box has all cities that begin with the sequence you've typed so far, so you can, for example, choose between Glendale, Arizona and Glendale, California - or between London, United Kingdom and London, Canada. No need to select the country. However, if you can't provide a list of cities for whatever reason (including "it's a simple text-based UI and supporting that would be too complicated"), you might have to go through a country/zone name within that country selection menu. It might be possible to use the territory supplemental information: http://www.unicode.org/cldr/charts/latest/supplemental/territory_information... to get a list of countries, and use the main files to get the localized names for the countries. Unfortunately, there doesn't seem to be any obvious way to get a list of tzids for a country, which is the list you'd want

you need to get, somehow, a list of all metazones that apply to Brazil.

To quote http://unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names "Invariants: * At any given point in time, each zone belongs to no more than one metazone. * At a given point in time, a zone may not belong to any metazones. * Except for daylight savings, at any given time, all zones in a metazone have the same offset at that time." The second of those invariants means that getting a list of metazones would not be sufficient - the most appropriate zone for some user might not *be* in any metazone. The ideal time zone selector would need information from the CLDR *and* some additional information, such as boundaries of tzdb zones and lists of cities. I'm not sure how much of the additional information can, or should, be provided as part of the tzdb itself. I'm also not sure how much of it can, or should, be provided by the CLDR. For what it's worth, here: http://efele.net/maps/tz/world/ is a shapefile that "captures the boundaries of the TZ timezones across the world, as of TZ 2013b". There might also be useful information available from geonames.org and openstreetmap.org. But if you're stuck with presenting a list of "time zones" from which to select, that might require yet another database. I'm not sure whether that'd be in the scope of the tzdb or the CLDR or neither of them - and for some locations, the appropriate tzdb zone might not really have a good name, other than what it's called now or "XXX time" if it's shuffled between differently named zones or is one of those "XXX time except that we don't do DST" zones.

On Oct 11, 2015, at 4:17 AM, Lester Caine <lester@lsces.co.uk> wrote:

On 11/10/15 04:00, Guy Harris wrote:

...

But if you're stuck with presenting a list of "time zones" from which to select, that might require yet another database. I'm not sure whether that'd be in the scope of the tzdb or the CLDR or neither of them - and for some locations, the appropriate tzdb zone might not really have a good name, other than what it's called now or "XXX time" if it's shuffled between differently named zones or is one of those "XXX time except that we don't do DST" zones.

The basic fact is that tz provides a limited set of generic rules. In hindsight this may have been better identified as a simple numeric ID?

Or alphanumeric - anything to keep UI developers from "cheaping out" and, in the tzdb zone selection UI just displaying tzids or slightly-tweaked tzids (e.g., turning underscores into spaces, which wouldn't really make the UI much better; for example, offering "Los Angeles" as the choice for everybody on the US West Coast isn't much of an improvement over "America/Los_Angeles"), with the result that people complain here that the tzids mention the "wrong" city.

That these rules ONLY apply to time data later than 1970 sweeps the problem of identifying just were some places were located earlier than that under the carpet,

I think that's the intent - to keep it out of scope of the tzdb. As Paul has noted, the further we go back in time, the harder it is to find *correct* time zone information. Go back far enough, and there *is* no standard time, and the "tzid" would end up being a longitude+latitude and you'd just calculate local time from that.

On Oct 9, 2015, at 1:05 PM, MARCIO IKEDA <marcio.ikeda@lge.com> wrote:

It is strange that in Brazil we have 4 major timezone areas:

The US and Canada each have more than that, so there's nothing strange about that. Russia has several time zones as well.

People in Brazil, call it as “Horario de Brasilia” as the main timezone.

In Windows it displays Brasilia for user.s

*Only* Brasilia? There are several other cities in that time zone....

In iOS has the Brasilia entry as well.

In iOS 9 on our iPad Air, in the "Time Zone" page for "Date & Time", you can type a number of different cities, including Brasilia, São Paulo, Rio de Janeiro, etc., and it will show the time zone by giving the city name you entered, rather than as "Horario de Brasilia" or "Brasilia Standard Time". Perhaps it displays the name of the time zone somewhere else.

In Android (my interested area) the timezone list uses Exemplar location, so “Sao Paulo” is shown.

If by "Exemplar location" you mean "the city whose name is used in the tzid", and that city is what they're displaying in the user interface as an indication of what time zone you're in, then that's incorrect behavior on Android's part.

I don`t know how other systems manages timezones.

OS X has, in an English locale, "Brasilia Standard Time", which includes Brasilia, Sao Paolo, Rio de Janeiro, etc..

But it is sure that there is some mismatching.

Yes, Android is broken, and, apparently, doesn't make full use of the CLDR (or perhaps makes *no* use of the CLDR). It should be fixed to do more than just show the city from the tzid.

What do you guys think ?

An entry like America/Brasilia, mapping to America/Sao_Paulo and changing displayName would be the solution ?

No, a fix to Android not to treat the tzid as something to be shown in the UI would be the solution. Windows doesn't use the tzdb, but iOS does, and it manages to use the tzdb *and* still show the main Brazilian time zone as (Horário de) Brasilia, so it *is* possible to do the right thing without adding an alias for America/Sao_Paolo. There is no "displayName" in the tzdb; that's a CLDR feature - and I don't see any displayName associated with zones or metazones. I see <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> in the pt.xml file, but that's OK as it is.

On Oct 9, 2015, at 12:43 PM, Matt Johnson <mj1856@hotmail.com> wrote:

Hi Marcio!

"Metazone" is a CLDR term. See: http://www.unicode.org/reports/tr35/tr35-dates.html#Metazone_Names http://unicode.org/repos/cldr/trunk/common/supplemental/metaZones.xml

Speaking of the CLDR, presumably, in http://www.unicode.org/reports/tr35/tr35-dates.html#Using_Time_Zone_Names when it says Generic location format: Reflects "wall time": a primary function of this format type is to represent a time zone in a list or menu for user selection of time zone, since the naming is more uniform than the generic non-location format and zones for the same country will be grouped together (and could be organized hierarchically by country if desired). It is also a fallback format when there is no translation for the generic non-location format. * "Los Angeles Time" * "Italy Time". Note: A generic location format is constructed by a part of time zone ID representing an exemplar city name or its country as the final fallback. "final fallback" means "only if there is nothing else available as a name representing the time zone", so that, for example, in a Brazilian Portuguese locale, the tzdb zone "America/Sao_Paulo" is represented as "Hora de Brasilia" rather than using the final fallback and ending up with something containing "Paulo", and, in a US English locale, the tzdb zone "America/Los_Angeles" is represented as "Pacific Time (US)" or something such as that. I am currently about 500 km from Los Angeles, and my clock is not on "Los Angeles Time", it's on Pacific Time (with DST being honored). Fortunately, the OS on which I'm typing this - which makes significant use of the CLDR - never offers me "Los Angeles Time" as the appropriate time zone for me. (It often likes speaking of "Cupertino" in that process, which should suggest what OS it is. :-)) Its time zone selector, using Location Services, correctly determines that the closest city to me is Palo Alto (which is where I am), and, in the drop-down box, offers a choice of California and Nevada cities, as well as Tijuana. (The choice doesn't include every city in California; I think it filters out nearby cities.) It offers those, rather than offering a time zone name, in the drop-down box, although if you either select a city or type one in, it displays the current time zone name - "Pacific Daylight Time", currently, and you can click to switch between the full name and the abbreviation. It displays "Brasilia Standard Time" if I type in either Brasilia, São Paulo, or Rio de Janeiro (or, I suspect, other cities in the main Brazilian time zone). The correct meta-algorithm for deciding how a time zone selection algorithm should work is: IF you can get location information and can map location information to a tzid THEN use that to find the appropriate tzid, and offer the user an option to disable that; ELSEIF (you can't OR the user told you not to) AND you can provide a list of cities/other locations (*multiple* cities per tzdb zone, if there are multiple cities; don't just give the exemplar city) AND you can map those locations to tzids THEN let the user select from a list of cities/other locations ELSEIF you at least have a list of tzids AND you can map them to the locale's name for the zone THEN let the user select from a list of localized names for the zone (e.g., "Hora de Brasilia", not "Hora de São Paulo" or something such as that) ELSE you may be stuck with presenting exemplar cities or tzids, but really try not to get stuck there ENDIF

Guy Harris wrote:

Would it be at all useful for the tzdb to itself maintain the notion of metazones, perhaps giving a metazone name as an additional component of a Zone line?

Yes, that sounds useful to me. Any change to the tzdata format is problematic of course, but if we're going to change it we might as well make things easier for translators. There was a proposal a while ago to have Zone lines be chainable (e.g., Europe/Paris could say "we're just like Europe/Berlin from 1940-06-14 23:00 to 1944-08-25 00:00"), and metazones could be part of that chaining process somehow.