[tz] RES: Timezone for Brazil
Guy Harris
gharris at sonic.net
Tue Oct 10 06:25:00 UTC 2023
On Oct 9, 2023, at 5:45 PM, Fabrício Rennó <fabricio.renno at 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.
More information about the tz
mailing list