# IANA Timezone Name Key: `datetime.offset.iana` Timezone identifier from the IANA Time Zone Database (tz database). Used in most programming languages and operating systems. Page: Samples: `America/New_York`, `Europe/London`, `Asia/Tokyo` ## Background ### Origin 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.[[1]](https://en.wikipedia.org/wiki/Tz_database) The tz database's origins go back to 1986 or earlier.[[1]](https://en.wikipedia.org/wiki/Tz_database) RFC 6557 says that from the early 1980s through 2011 the database was hosted at the U.S. National Institutes of Health.[[2]](https://www.rfc-editor.org/rfc/rfc6557.txt) RFC 6557 describes the database as in use on nearly all UNIX systems, Java systems, and other sorts of systems.[[2]](https://www.rfc-editor.org/rfc/rfc6557.txt) ICANN took responsibility for the maintenance of the tz database on 14 October 2011.[[1]](https://en.wikipedia.org/wiki/Tz_database) The tz database's uniform naming convention, with names such as America/New\_York and Europe/Paris, was designed by Paul Eggert.[[1]](https://en.wikipedia.org/wiki/Tz_database) The tz project's naming guidelines say names normally have the format AREA/LOCATION, where AREA is a continent or ocean and LOCATION is a specific location within the area.[[3]](https://data.iana.org/time-zones/theory.html) Under the tz naming guidelines, North and South America share the same area, America.[[3]](https://data.iana.org/time-zones/theory.html) The tz naming guidelines say names are typically not tied to countries, to avoid incompatibilities when countries change their name or when locations change countries.[[3]](https://data.iana.org/time-zones/theory.html) The tz naming guidelines prefer cities or small islands to countries or regions, so that future changes do not split individual locations into different timezones, giving Europe/Paris over Europe/France as an example.[[3]](https://data.iana.org/time-zones/theory.html) Some tz names are further qualified to avoid confusion, as in America/Indiana/Petersburg.[[3]](https://data.iana.org/time-zones/theory.html) The tz naming guidelines say a file name component must not exceed 14 characters.[[3]](https://data.iana.org/time-zones/theory.html) ### Use PostgreSQL accepts a full time zone name such as America/New\_York and uses the IANA time zone data for this purpose.[[4]](https://www.postgresql.org/docs/current/datatype-datetime.html) PostgreSQL's documentation says that for a time with time zone value using a name with a daylight-savings rule, such as America/New\_York, a date is required to determine whether standard or daylight-savings time applies.[[4]](https://www.postgresql.org/docs/current/datatype-datetime.html) RFC 6557 says time zone names are used in DHCP to configure devices and can appear in the TZID field of calendaring VEVENTs.[[2]](https://www.rfc-editor.org/rfc/rfc6557.txt) Keep the zone name alongside the timestamp rather than replacing it with a single offset worked out once. (Meridian's view) The tz database's backward file provides links from old or merged timezone names to current ones.[[5]](https://data.iana.org/time-zones/tzdb/backward) The tz backward file links the old name US/Eastern to America/New\_York.[[5]](https://data.iana.org/time-zones/tzdb/backward) Expect old spellings in older files and normalise them through the backward links before grouping or joining on the zone column. (Meridian's view) There is no fixed schedule for tzdb releases, though typically a release occurs every few months.[[6]](https://data.iana.org/time-zones/tz-link.html) Validate zone names against the tzdata your own system ships rather than a hand-kept list, and expect a newer file to name a zone your copy does not know yet. (Meridian's view) ### Where you'll meet it The General Transit Feed Specification defines its Timezone field as a TZ timezone from the IANA database, with examples such as Asia/Tokyo, America/Los\_Angeles and Africa/Cairo.[[7]](https://gtfs.org/documentation/schedule/reference/) The GTFS agency.txt file has a required agency\_timezone field of the Timezone type.[[7]](https://gtfs.org/documentation/schedule/reference/) OpenFlights' airport data has a Tz database timezone column in Olson format, such as America/Los\_Angeles.[[8]](https://openflights.org/data.php) OpenFlights' sample entries include Europe/London for London Heathrow Airport and Asia/Katmandu for Pokhara Airport.[[8]](https://openflights.org/data.php) ## Sources 1. [tz database - Wikipedia](https://en.wikipedia.org/wiki/Tz_database) — secondary source 2. [Procedures for Maintaining the Time Zone Database](https://www.rfc-editor.org/rfc/rfc6557.txt) — standard 3. [Theory and pragmatics of the tz code and data](https://data.iana.org/time-zones/theory.html) — documentation 4. [PostgreSQL: Documentation: 18: 8.5. Date/Time Types](https://www.postgresql.org/docs/current/datatype-datetime.html) — documentation 5. [backward](https://data.iana.org/time-zones/tzdb/backward) — documentation 6. [Time zone and daylight saving time data](https://data.iana.org/time-zones/tz-link.html) — documentation 7. [Reference - General Transit Feed Specification](https://gtfs.org/documentation/schedule/reference/) — organisation 8. [OpenFlights: Airport and airline data](https://openflights.org/data.php) — dataset