Tz database

Last updated

The tz database partitions the world into regions where local clocks all show the same time. This map was made by combining version 2023d of the List of tz database time zones with OpenStreetMap data, using open source software. Timezone-boundary-builder release 2023d.png
The tz database partitions the world into regions where local clocks all show the same time. This map was made by combining version 2023d of the List of tz database time zones with OpenStreetMap data, using open source software.

The tz database is a collaborative compilation of information about the world's time zones and rules for observing daylight saving time, primarily intended for use with computer programs and operating systems. [2] Paul Eggert has been its editor and maintainer since 2005, [3] with the organizational backing of ICANN. [4] The tz database is also known as tzdata, the zoneinfo database or the IANA time zone database (after the Internet Assigned Numbers Authority), and occasionally as the Olson database, referring to the founding contributor, Arthur David Olson. [5]

Contents

Its uniform naming convention for entries in the database, such as America/New_York and Europe/Paris, was designed by Paul Eggert. [6] The database attempts to record historical time zones and all civil changes since 1970, the Unix time epoch. [7] It also records leap seconds. [8]

The database, as well as some reference source code, is in the public domain. [9] New editions of the database and code are published as changes warrant, usually several times per year. [10]

Data structure

Definition of a timezone

Within the tz database, a timezone is any national region where local clocks have all agreed since 1970. [11] This definition concerns itself first with geographic areas which have had consistent local clocks. A timezone is different from a region with a particular standard time offset from UTC, which is often referred to as a "time zone". Therefore, each of the timezones defined by the tz database may use multiple offsets from UTC, such as offsets for standard time and daylight saving time. [12]

File formats

The tz database is published as a set of text files which list the rules and zone transitions in a human-readable format. For use, these text files are compiled into a set of platform-independent binary files—one per timezone. The reference source code includes such a compiler called zic (zone information compiler), as well as code to read those files and use them in standard APIs such as localtime() and mktime().

Timezones

Each timezone has one or more "zone lines" in one of the tz database text files. The first zone line for a timezone gives the name of the timezone; any subsequent zone lines for that timezone leave the name blank, indicating that they apply to the same zone as the previous line. Each zone line for a zone specifies, for a range of date and time, the offset to UTC for standard time, the name of the set of rules that govern daylight saving time (or a hyphen if standard time always applies), the format for time zone abbreviations, and, for all but the last zone line, the date and time at which the range of date and time governed by that line ends.

Daylight saving time (DST) rules

The rules for daylight saving time are specified in named rule sets. Each rule set has one or more rule lines in the text files. A rule line contains the name of the rule set to which it belongs, the first year in which the rule applies, the last year in which the rule applies (or "only" if it applies only in one year or "max" if it is the rule then in effect), the type of year to which the rule applies ("-" if it applies to all years in the specified range, which is almost always the case, otherwise a name used as an argument to a script that indicates whether the year is of the specified type), the month in which the rule takes effect, the day on which the rule takes effect (which could either be a specific day or a specification such as "the last Sunday of the month"), the time of day at which the rule takes effect, the amount of time to add to the offset to UTC when the rule is in effect, and the letter or letters to use in the time zone abbreviation (for example, "S" if the rule governs standard time and "D" if it governs daylight saving time).

Names of timezones

The timezones have unique names in the form "Area/Location", e.g. "America/New_York". A choice was also made to use English names or equivalents, and to omit punctuation and common suffixes. The underscore character is used in place of spaces. Hyphens are used where they appear in the name of a location. The Area and Location names have a maximum length of 14 characters. [13] [14]

Area

Area is the name of a continent, an ocean, or "Etc". The continents and oceans used are Africa, America, Antarctica, Arctic, Asia, Atlantic, Australia, Europe, Indian, and Pacific.

The oceans are included since some islands are hard to connect to a certain continent. Some are geographically connected to one continent and politically to another. See also Boundaries between continents.

The special area of "Etc" is used for some administrative zones, particularly for "Etc/UTC" which represents Coordinated Universal Time. In order to conform with the POSIX style, those zone names beginning with "Etc/GMT" have their sign reversed from the standard ISO 8601 convention. In the "Etc" area, zones west of GMT have a positive sign and those east have a negative sign in their name (e.g "Etc/GMT-14" is 14 hours ahead of GMT).

Location

Location is the name of a specific location within the area – usually a city or small island.

Country names are not normally used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. [15] Usually the most populous city in a region is chosen to represent the entire timezone, although another city may be selected if it is more widely known, and another location, including a location other than a city, may be used if it results in a less ambiguous name. [16] In the event that the name of the location used to represent the timezone changes, the convention is to create an alias [17] in future editions so that both the old and new names refer to the same database entry.

In some cases the Location is itself represented as a compound name, for example the timezone "America/Indiana/Indianapolis". Three-level names include those under "America/Argentina/...", "America/Kentucky/...", "America/Indiana/...", and "America/North_Dakota/...".

The location selected is representative for the entire area. However, if there were differences within the area before 1970, the time zone rules only apply in the named location.

Examples

NameExplanation
America/Costa_Rica name of country used because the name of the largest city (and capital city) San José is ambiguous
America/New_York Space replaced with underscore
Asia/Kolkata name of city of Kolkata used, because it was the most populous city in the zone at the time the zone was set up, though this is no longer true [18]
Asia/Sakhalin name of island used, because largest city, Yuzhno-Sakhalinsk, has more than 14 characters
America/Bahia_Banderas "de" removed from Bahia de Banderas, because correct name has more than 14 characters
Antarctica/DumontDUrville the apostrophe is removed. The space would normally be replaced with "_", but the name would then exceed 14 characters.

Example zone and rule lines

These are rule lines for the standard United States daylight saving time rules, rule lines for the daylight saving time rules in effect in the US Eastern Time Zone (called "NYC" as New York City is the city representing that zone) in some years, and zone lines for the America/New_York timezone, as of release version tzdata2011n of the time zone database. The zone and rule lines reflect the history of DST in the United States.

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S Rule    US      1918    1919    -       Mar     lastSun 2:00    1:00    D Rule    US      1918    1919    -       Oct     lastSun 2:00    0       S Rule    US      1942    only    -       Feb     9       2:00    1:00    W # War Rule    US      1945    only    -       Aug     14      23:00u  1:00    P # Peace Rule    US      1945    only    -       Sep     30      2:00    0       S Rule    US      1967    2006    -       Oct     lastSun 2:00    0       S Rule    US      1967    1973    -       Apr     lastSun 2:00    1:00    D Rule    US      1974    only    -       Jan     6       2:00    1:00    D Rule    US      1975    only    -       Feb     23      2:00    1:00    D Rule    US      1976    1986    -       Apr     lastSun 2:00    1:00    D Rule    US      1987    2006    -       Apr     Sun>=1  2:00    1:00    D Rule    US      2007    max     -       Mar     Sun>=8  2:00    1:00    D Rule    US      2007    max     -       Nov     Sun>=1  2:00    0       S .... # Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER Rule    NYC     1920    only    -       Mar     lastSun 2:00    1:00    D Rule    NYC     1920    only    -       Oct     lastSun 2:00    0       S Rule    NYC     1921    1966    -       Apr     lastSun 2:00    1:00    D Rule    NYC     1921    1954    -       Sep     lastSun 2:00    0       S Rule    NYC     1955    1966    -       Oct     lastSun 2:00    0       S # Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL] Zone America/New_York   -4:56:02 -      LMT     1883 November 18, 12:03:58                         -5:00   US      E%sT    1920                         -5:00   NYC     E%sT    1942                         -5:00   US      E%sT    1946                         -5:00   NYC     E%sT    1967                         -5:00   US      E%sT 

Data stored for each zone

For each timezone that has multiple offsets (usually due to daylight saving time), the tz database records the exact moment of transition. The format can accommodate changes in the dates and times of transitions as well. Zones may have historical rule changes going back many decades (as shown in the example above).

Zone.tab

The file zone.tab is in the public domain and lists the zones. Columns and row sorting are described in the comments of the file, as follows:

# This file contains a table with the following columns: # 1.  ISO 3166 2-character country code.  See the file `iso3166.tab'. # 2.  Latitude and longitude of the zone's principal location #     in ISO 6709 sign-degrees-minutes-seconds format, #     either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS, #     first latitude (+ is north), then longitude (+ is east). # 3.  Zone name used in value of TZ environment variable. # 4.  Comments; present if and only if the country has multiple rows. #  # Columns are separated by a single tab. # The table is sorted first by country, then an order within the country that # (1) makes some geographical sense, and # (2) puts the most populous zones first, where that does not contradict (1).

Data before 1970

Data before 1970 aims to be correct for the city identifying the region, but is not necessarily correct for the entire region. This is because new regions are created only as required to distinguish clocks since 1970.

For example, between 1963-10-23 and 1963-12-09 in Brazil only the states of Minas Gerais, Espirito Santo, Rio de Janeiro, and São Paulo had summer time. However, a requested split from America/Sao_Paulo was rejected in 2010 with the reasoning that, since 1970, the clocks were the same in the whole region. [19]

Time in Germany, which is represented by Europe/Berlin, is incorrect for the year 1945 when the Trizone used daylight saving time rules different from Berlin's. [20]

Coverage

Zones covering multiple post-1970 countries

There are two zones that cover an area that was covered by two countries after 1970. The database follows the definitions of countries as per ISO 3166-1, whose predecessor, ISO 3166, was first published in 1974.

Maintenance

The tz reference code and database is maintained by a group of volunteers. Arthur David Olson makes most of the changes to the tz reference code. Paul Eggert makes most of the changes to the tz database. Proposed changes are sent to the tz mailing list, which is gatewayed to the comp.time.tz Usenet newsgroup. Source files are distributed via the IANA FTP server. Typically, these files are taken by a software distributor like Debian, compiled, and then the source and binaries are packaged as part of that distribution. End users can either rely on their software distribution's update procedures, which may entail some delay, or obtain the source directly and build the binary files themselves. The IETF has published RFC   6557, "Procedures for Maintaining the Time Zone Database" documenting best practices based on similar principles.

Unix-like systems

The standard path for the timezone database is /usr/share/zoneinfo/ in Linux distributions, macOS, and some other Unix-like systems.

Usage and extensions

Boundaries of timezones

Geographical boundaries in the form of coordinate sets are not part of the tz database, but boundaries are published by Evan Siroky [1] in GeoJSON and shapefile formats.

Use in other standards

The Unicode Common Locale Data Repository (CLDR) refers to zones in the tz database. However, as the name for a zone can change from one tz database release to another, the CLDR assigns the UN/LOCODE for the city used in the name for the zone, or an internally-assigned code if there is no such city for the zone, to a tzdb zone. [21] [22]

Use in software systems

The tz database is used for time zone processing and conversions in many computer software systems, including:

The Olson timezone IDs are also used by the Unicode Common Locale Data Repository (CLDR) and International Components for Unicode (ICU). For example, the CLDR Windows–Tzid table maps Microsoft Windows time zone IDs to the standard Olson names, although such a mapping cannot be perfect because the number of time zones in Windows systems is significantly lower than in the IANA TZ database. [33]

History

The project's origins go back to 1986 or earlier. [34]

2011 lawsuit

On 30 September 2011, a lawsuit, Astrolabe, Inc. v. Olson et al., was filed concerning copyright in the database. [35] [36] As a result, on 6 October 2011, the database's mailing list and FTP site were shut down. [37] The case revolved around the database maintainers' use of The American Atlas, by Thomas G. Shanks, and The International Atlas, by Thomas G. Shanks and Rique Pottenger. It complained of unauthorised reproduction of atlas data in the timezone mailing list archive and in some auxiliary link collections maintained with the database, though it did not actually point at the database itself. The complaint related only to the compilation of historical timezone data, and did not cover extant tzdata world timezone tables. [36] [38] [39]

This lawsuit was resolved on 22 February 2012 after the involvement of the Electronic Frontier Foundation, when Astrolabe voluntarily moved to dismiss the lawsuit without having ever served the defendants and agreed to a covenant not to sue in the future. [40]

Move to ICANN

ICANN took responsibility for the maintenance of the database on 14 October 2011. [4] The full database and a description of plans for its maintenance are available online from IANA. [41]

See also

Related Research Articles

<span class="mw-page-title-main">Time zone</span> Area that observes a uniform standard time

A time zone is an area which observes a uniform standard time for legal, commercial and social purposes. Time zones tend to follow the boundaries between countries and their subdivisions instead of strictly following longitude, because it is convenient for areas in frequent communication to keep the same time.

<span class="mw-page-title-main">Time in Germany</span>

The time zone in Germany is Central European Time and Central European Summer Time. Daylight saving time is observed from the last Sunday in March to the last Sunday in October. The doubled hour during the switch back to standard time is named 2A and 2B.

<span class="mw-page-title-main">Time in Svalbard</span>

Svalbard, an archipelago in the Arctic Ocean belonging to the Kingdom of Norway, uses Central European Time (CET) during the winter as standard time, which is one hour ahead of Coordinated Universal Time (UTC+01:00), and Central European Summer Time (CEST) during the summer as daylight saving time, which is two hours ahead of Coordinated Universal Time (UTC+02:00). This is shared with the rest of Norway, as is Svalbard's use of daylight saving time, which the territory observes annually by advancing the clock forward on the last Sunday in March and back again on the last Sunday in October. However, as Svalbard experiences midnight sun during the summer due to being located north of the Arctic Circle, it gives daylight saving time no utility, and is only observed in order to make communicating with Norway Proper more convenient. At the 74th parallel north, the midnight sun lasts 99 days and polar night 84 days, while the respective figures at the 81st parallel north are 141 and 128 days.

<span class="mw-page-title-main">Time in Libya</span>

Time in Libya is given by a single time zone, officially denoted as Eastern European Time. The zone is also known as Central Africa Time (CAT). Libya has observed EET since 5 November 2012, after it was announced in 2013 that Libya would be on permanent daylight saving time. Libya previously observed several different time zones as standard time and daylight saving time. For residents of western Libya, including Tripoli, solar time is usually one hour behind standard time.

Time in Sudan is given by a single time zone, officially denoted as Central Africa Time. Sudan has observed CAT since 1 November 2017. Sudan has not observed daylight saving time since 14 October 1985.

Time in the island country of São Tomé and Príncipe is given by Greenwich Mean Time. São Tomé and Príncipe has never observed daylight saving time.

Time in Rwanda is given by a single time zone, officially denoted as Central Africa Time. Rwanda has never observed daylight saving time.

Time in Zambia is given by a single time zone, officially denoted as Central Africa Time. Zambia has never observed daylight saving time. Zambia, as North-Eastern Rhodesia, has observed CAT since 1903.

Time in Zimbabwe is given by a single time zone, officially denoted as Central Africa Time. Zimbabwe has never observed daylight saving time. Zimbabwe, as Southern Rhodesia, has observed CAT since 1903.

Time in Burundi is given by a single time zone, officially denoted as Central Africa Time. Burundi does not observe daylight saving time.

Time in Malawi is given by a single time zone, officially denoted as Central Africa Time. Malawi does not observe daylight saving time.

Time in Djibouti is given by a single time zone, officially denoted as East Africa Time. Djibouti does not observe daylight saving time.

Time in Comoros is given by a single time zone, officially denoted as East Africa Time. Comoros does not observe daylight saving time.

Time in Tanzania is given by a single time zone, officially denoted as East Africa Time. Tanzania does not observe daylight saving time.

Time in Uganda is given by a single time zone, officially denoted as East Africa Time. Uganda does not observe daylight saving time.

Time in the Gambia is given by a single time zone, denoted as Greenwich Mean Time. Adopted in 1918, the Gambia has never observed daylight saving time (DST).

Time in Ivory Coast is given by a single time zone, denoted as Greenwich Mean Time. Adopted on 1 January 1911, the Ivory Coast has never observed daylight saving time (DST).

Time in Togo is given by Greenwich Mean Time. Togo has never observed daylight saving time and adopted this time zone in 1907.

Nigeria observes West Africa Time (WAT), which is one hour ahead of Coordinated Universal Time (UTC+01:00), year-round as standard time. Nigeria has never observed daylight saving time. It shares WAT with fourteen other countries in Africa. Nigeria's local mean time was UTC+00:13:35.

Time in Botswana is given by a single time zone, officially denoted as Central Africa Time. Botswana has never observed daylight saving time. Botswana, as the Bechuanaland Protectorate, has observed CAT since 1903. In 1885 it used the South African Standard Time as British Bechuanaland. Before adopting SAST and CAT, it observed local mean time.

References

  1. 1 2 Siroky, Evan (1 January 2024). "Time Zone Boundary Builder". GitHub .
  2. Eggert, Paul; Olson, Arthur David. "Time zone and daylight saving time data". Archived from the original on 8 March 2021. Retrieved 23 April 2024.
  3. Eggert, Paul (17 January 2005). "Re: FW: IANA time zone registration – proposal". tz (Mailing list).
  4. 1 2 "ICANN to Manage Time Zone Database" (news alert). ICANN. 15 October 2011. Archived from the original on 13 December 2014. Retrieved 30 December 2011.
  5. Olson, Arthur David (16 December 1986). "Resolved timezone issue? Other issues. New ctime manual page". tz (Mailing list). Archived from the original on 9 March 2021. Retrieved 24 October 2018.
  6. Eggert, Paul (20 October 1993). "proposal for time zone names". tz (Mailing list). Archived from the original on 27 September 2016. Retrieved 25 September 2016.
  7. Olson, Arthur David (18 March 1987). "Re: List of issues". tz (Mailing list). Archived from the original on 8 March 2021. Retrieved 27 October 2018.
  8. Devine, Bob (2 June 1988). "leap seconds; [0-60] is ok". tz (Mailing list). Archived from the original on 11 April 2016. Retrieved 18 June 2015.
  9. Eggert, Paul (11 November 1995). "questions and comments on http://tycho.usno.navy.mil/tzones.html". tz (Mailing list). Archived from the original on 8 March 2021. Retrieved 27 October 2018.
  10. "zoneinfo tzcode and tzdata archives (FTP)". Archived from the original on 26 September 2024. Retrieved 30 October 2007.
  11. "Theory and pragmatics of the tz code and data". Archived from the original on 5 March 2021. Retrieved 16 December 2020.
  12. "Scope of the tz database". Theory and pragmatics of the tz code and data. Archived from the original on 17 April 2024. Retrieved 23 April 2024. 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.
  13. Olson, Arthur David (1 May 2010). "proposed time zone package changes (Bahia de Banderas; version naming)". tz (Mailing list). Archived from the original on 8 March 2021. Retrieved 27 October 2018.
  14. "Timezone identifiers". Theory and pragmatics of the tz code and data. Archived from the original on 26 September 2024. Retrieved 16 December 2020. Use only valid POSIX file name components (i.e., the parts of names other than '/'). Do not use the file name components '.' and '..'. Within a file name component, use only ASCII letters, '.', '-' and '_'. Do not use digits, as that might create an ambiguity with POSIX TZ strings. A file name component must not exceed 14 characters or start with '-'. E.g., prefer Asia/Brunei to Asia/Bandar_Seri_Begawan. Exceptions: see the discussion of legacy names below.
  15. "Timezone identifiers". Theory and pragmatics of the tz code and data. Archived from the original on 26 September 2024. Retrieved 16 December 2020. 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 timezones.
  16. "Timezone identifiers". Theory and pragmatics of the tz code and data. Archived from the original on 5 March 2021. Retrieved 16 December 2020. Here are the general guidelines used for choosing timezone names, in decreasing order of importance: ... If a name is ambiguous, use a less ambiguous alternative; e.g., many cities are named San José and Georgetown, so prefer America/Costa_Rica to America/San_Jose and America/Guyana to America/Georgetown. ... 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.
  17. "Timezone identifiers". Theory and pragmatics of the tz code and data. Archived from the original on 26 September 2024. Retrieved 16 December 2020. If a name is changed, put its old spelling in the 'backward' file. This means old spellings will continue to work. Ordinarily a name change should occur only in the rare case when a location's consensus English-language spelling changes; for example, in 2008 Asia/Calcutta was renamed to Asia/Kolkata due to long-time widespread use of the new city name instead of the old.
  18. Paul Eggert (21 December 2012). "Re: zoneinfo : ist : error". tz (Mailing list). Archived from the original on 30 May 2022. Retrieved 19 March 2013.
  19. Olson, Arthur David (6 January 2010). "RE: little nuance in brazil 1963". tz (Mailing list). Archived from the original on 25 April 2019. Retrieved 25 April 2019.
  20. "DST and midsummer DST in Germany until 1979". Physikalisch-Technische Bundesanstalt.
  21. "Unicode Locale Extension ('u') for BCP 47". CLDR – Unicode Common Locale Data Repository. Archived from the original on 28 July 2011. Retrieved 18 February 2011.
  22. "Unicode Locale Data Markup Language (LDML), Part 4: Dates". section 5, Time Zone Names. Archived from the original on 23 March 2018. Retrieved 24 March 2018.
  23. "Olson time zone support and setup". AIX 7.3 Documentation. IBM. Retrieved 26 September 2024.
  24. "Managing the Time Zone Variable (POSIX)". IBM. 2 February 2007. Retrieved 26 September 2024.
  25. 1 2 "AIX O/S updated to support 2007 Daylight Saving Time change". IBM. 18 October 2007. Archived from the original on 11 April 2016. Retrieved 12 March 2011.
  26. "2007 daylight savings [sic] time changes for Unix". Academic Computing and Communications Center, University of Illinois at Chicago. 25 February 2007. Archived from the original on 5 August 2012. Retrieved 18 March 2008.)
  27. Wickremasinghe, Christopher (30 March 2009). "Introduction of daylight saving time in Western Australia 2006". AIX Wiki. IBM. Archived from the original on 24 October 2012. Retrieved 11 March 2011.
  28. "ZoneId". developer.android.com. Archived from the original on 14 September 2018. Retrieved 14 September 2018.
  29. Release 4.0 Change Notes for the Sun Workstation (PDF). Sun Microsystems. 19 January 1987. p. 4. Archived (PDF) from the original on 7 March 2022. Retrieved 6 March 2022.
  30. "ECMAScript 2015 Internationalization API Specification". ecma-international.org (2nd ed.). June 2015. Archived from the original on 26 October 2019. Retrieved 14 January 2020. The ECMAScript 2015 Internationalization API Specification identifies time zones using the Zone and Link names of the IANA Time Zone Database. Their canonical form is the corresponding Zone name in the casing used in the IANA Time Zone Database. ... It is recommended that implementations use the time zone information of the IANA Time Zone Database.
  31. "TZDB library moved to GitHub on April 23, 2014". Archived from the original on 24 February 2021. Retrieved 21 October 2015.
  32. Oracle Database Globalization Support Guide 10g Release 1 (10.1): Chapter 4, Section "Choosing a Time Zone File". Oracle Corporation. June 2004. pp. 4–14. Part No. B10749-02. Archived from the original on 1 December 2008. Retrieved 30 October 2007.
  33. "Windows → Tzid". Unicode Consortium. 12 November 2007. Archived from the original on 3 May 2013. Retrieved 17 February 2008.
  34. Olson, Arthur David (24 November 1986). "seismo!elsie!tz ; new versions of time zone stuff". tz (Mailing list). Archived from the original on 26 September 2024. Retrieved 13 June 2017.
  35. "Astrolabe, Inc. v. Olson et al". 6 October 2011. Retrieved 26 September 2024.
  36. 1 2 "ASTROLABE, INC., Plaintiff, v. ARTHUR DAVID OLSON and PAUL EGGERT, Defendants" (PDF). 30 September 2011. Archived from the original (PDF) on 14 March 2012. Retrieved 7 October 2011.
  37. Olson, Arthur David (6 October 2011). "Civil suit; ftp shutdown; mailing list shutdown". tz (Mailing list). Archived from the original on 8 March 2021. Retrieved 27 October 2018.
  38. "Time zone database shut down". The Daily Parker. 6 October 2011. Retrieved 26 September 2024.
  39. "Time-zone database – Astrolabe's opinion". Stephen Colebourne's blog. 13 October 2011. Archived from the original on 14 October 2011. Retrieved 26 October 2011.
  40. "EFF Wins Protection for Time Zone Database". Electronic Frontier Foundation. 22 February 2012. Archived from the original on 23 February 2012. Retrieved 22 February 2012.
  41. "Time Zone Database". IANA. Archived from the original on 17 October 2011. Retrieved 23 November 2018.

General

Official IANA sources

Man pages