tz database - tz database

Tz -databasen deler verden inn i regioner der lokale klokker siden 1970 har vært de samme. Dette kartet, laget ved å kombinere 2017a -utgaven av databasen med OpenStreetMap -data, er fra alle regionene utenfor Antarktis.

Den tz database er et samarbeids samling av informasjon om verdens tidssoner , først og fremst beregnet for bruk med dataprogrammer og operativsystemer. Paul Eggert er nåværende redaktør og vedlikeholder, med organisatorisk støtte fra ICANN . Tz -databasen er også kjent som tzdata , zoneinfo -databasen eller IANA -tidssonedatabasen , og noen ganger som Olson -databasen , med henvisning til den grunnleggende bidragsyteren, Arthur David Olson.

Den ensartede navnekonvensjonen for tidssoner, for eksempel America/New_York og Europe/Paris , ble designet av Paul Eggert. Databasen prøver å registrere historiske tidssoner og alle sivile endringer siden 1970, Unix -tidsepoken. Den inkluderer også overganger som sommertid , og registrerer også sprang sekunder .

Databasen, samt noen referanse kildekoden er i public domain . Nye utgaver av databasen og koden publiseres som endringer krever, vanligvis flere ganger i året.

Data struktur

Filformater

Tz-databasen er publisert som et sett med tekstfiler som viser regler og soneoverganger i et lesbart format. For bruk blir disse tekstfilene samlet til et sett med plattformuavhengige binære filer-én per tidssone. Referansekildekoden inkluderer en slik kompilator kalt zic (soneinformasjonskompilator), samt kode for å lese disse filene og bruke dem i standard APIer som localtime()og mktime().

Definisjon av en tidssone

I tz -databasen er en tidssone en hvilken som helst nasjonal region der lokale klokker har vært enige siden 1970. Denne definisjonen gjelder først og fremst geografiske områder som har hatt konsekvente lokale klokker. Dette er forskjellig fra andre definisjoner som angår konsistente forskyvninger fra en primær meridian . Derfor kan hver av tidssonene definert av tz -databasen dokumentere flere forskyvninger fra UTC , vanligvis inkludert både standard tid og sommertid .

I tidssone -tekstfilene har hver tidssone en eller flere "sonelinjer" i en av tidssone -tekstfilene. Den første sonelinjen for en tidssone gir navnet på tidssonen; eventuelle påfølgende sonelinjer for den tidssonen lar navnet stå tomt, noe som indikerer at de gjelder for den samme sonen som forrige linje. Hver sonelinje for en sone angir, for et område av dato og klokkeslett, forskyvningen til UTC for standardtid, navnet på settet med regler som regulerer sommertid (eller en bindestrek hvis standardtid alltid gjelder), formatet for tidssone -forkortelser, og for alle unntatt den siste sonelinjen, datoen og klokkeslettet da dato- og klokkeslettet som styres av denne linjen slutter.

Sommertid (DST) regler

Reglene for sommertid er spesifisert i navngitte regelsett. Hvert regelsett har en eller flere regellinjer i tidssone -tekstfilene. En regellinje inneholder navnet på regelsettet som den tilhører, det første året regelen gjelder, det siste året regelen gjelder (eller "bare" hvis den bare gjelder på ett år eller "maks" hvis den er regelen som gjelder nå), årstypen som regelen gjelder ("-" hvis den gjelder alle år i det angitte området, noe som nesten alltid er tilfelle, ellers brukes et navn som et argument for et skript som angir om året er av den angitte typen), måneden regelen trer i kraft, dagen regelen trer i kraft (som enten kan være en bestemt dag eller en spesifikasjon som "den siste søndagen i måneden") , tidspunktet på dagen regelen trer i kraft, hvor lang tid det skal legges til forskyvningen til UTC når regelen er i kraft, og bokstaven eller bokstavene som skal brukes i tidssone -forkortelsen (for eksempel "S" hvis regelen regulerer standardtid og "D" hvis den regulerer sommertid).

Navn på tidssoner

Tidssonene har unike navn i formen " Areal / Location ", f.eks. "America / New_York". Et valg ble også tatt om å bruke engelske navn eller ekvivalenter, og å utelate skilletegn og vanlige suffikser. Understreketegnet brukes i stedet for mellomrom. Bindestreker brukes der de vises i navnet på et sted. De området og Sted navnene har en maksimal lengde på 14 tegn.

Område

Område er navnet på et kontinent , et hav eller "Etc". Kontinentene og havene som brukes nå er Afrika , Amerika , Antarktis , Arktis , Asia , Atlanterhavet , Australia , Europa , Indisk og Stillehavet .

Havene er inkludert siden noen øyer er vanskelige å koble til et bestemt kontinent. Noen er geografisk knyttet til ett kontinent og politisk til et annet. Se også Grenser mellom kontinenter .

Spesialområdet "Etc" brukes for noen administrative soner, spesielt for "Etc/UTC" som representerer koordinert universell tid . For å samsvare med POSIX -stilen, får sonene som begynner med "Etc/GMT", tegnet sitt omvendt fra standard ISO 8601 -konvensjon. I "Etc" -området har soner vest for GMT et positivt tegn, og de østlige har et negativt tegn i navnet sitt (f.eks. "Etc/GMT-14" er 14 timer foran GMT).

plassering

Beliggenhet er navnet på et bestemt sted i området - vanligvis en by eller en liten øy.

Landnavn brukes ikke i denne ordningen, først og fremst fordi de ikke ville være robuste på grunn av hyppige politiske og grenseendringer. Navnene på store byer pleier å være mer permanente. Vanligvis er den mest folkerike byen i en region valgt for å representere hele tidssonen, selv om en annen by kan velges hvis den er mer kjent, og et annet sted, inkludert et annet sted enn en by, kan brukes hvis det resulterer i en mindre tvetydig navn. I tilfelle navnet på stedet som brukes til å representere tidssonen endres, er konvensjonen å opprette et alias i fremtidige utgaver, slik at både det gamle og det nye navnet refererer til den samme databaseoppføringen.

I noen tilfeller Sted selv er representert som et sammensatt navn, for eksempel tidssonen " America / Indiana / Indianapolis ". Navn på tre nivåer inkluderer de under "America/Argentina/...", "America/Kentucky/...", "America/Indiana/..." og "America/North_Dakota/...".

Stedet som er valgt er representativt for hele området. Men hvis det var forskjeller innenfor området før 1970, gjelder tidssonereglene bare på det navngitte stedet.

Eksempler

Amerika/Costa_Rica navnet på landet som brukes fordi navnet på den største byen (og hovedstaden) San José er tvetydig
Amerika/New_York Plassen erstattet med understreking
Asia/Kolkata navnet på byen Kolkata brukt, fordi det var den mest folkerike byen i sonen på det tidspunktet sonen ble opprettet, selv om dette ikke lenger er sant
Asia/Sakhalin navnet på øya brukt, fordi den største byen, Yuzhno-Sakhalinsk , har mer enn 14 tegn
Amerika/Bahia_Banderas "de" fjernet fra Bahia de Banderas , fordi riktig navn har mer enn 14 tegn
Antarktis/DumontDUrville apostrofen er fjernet. Plassen vil normalt bli erstattet med "_", men navnet vil da overstige 14 tegn.

Eksempel på sone og regellinjer

Dette er regellinjer for de vanlige sommertidreglene i USA, regellinjer for sommertidreglene som gjelder i USAs østlige tidssone (kalt "NYC" ettersom New York City er byen som representerer den sonen) i noen år, og sonelinjer for tidssonen America/New_York, fra utgivelsesversjon tzdata2011n av tidssonedatabasen. Sone- og regellinjene gjenspeiler historien til DST i USA . 

# 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 lagret for hver sone

For hver tidssone som har flere forskyvninger (vanligvis på grunn av sommertid), registrerer tz -databasen det eksakte overgangstidspunktet. Formatet kan også ta imot endringer i datoene og tidspunktene for overgangene. Soner kan ha historiske regelendringer som går mange tiår tilbake (som vist i eksemplet ovenfor).

Zone.tab

Filen zone.tab er i det offentlige domene og viser sonene. Kolonner og ranksortering er beskrevet i kommentarene til filen, som følger: 

# 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 før 1970

Data før 1970 har som mål å være riktige for byen som identifiserer regionen, men er ikke nødvendigvis riktig for hele regionen. Dette er fordi nye regioner bare er opprettet etter behov for å skille klokker siden 1970.

For eksempel, mellom 1963-10-23 og 1963-12-09 i Brasil hadde bare delstatene Minas Gerais , Espirito Santo , Rio de Janeiro og São Paulo sommertid. Imidlertid ble en forespurt splittelse fra America/Sao_Paulo avvist i 2010 med den begrunnelsen at siden 1970 var klokkene like i hele regionen.

Tiden i Tyskland , som er representert av Europe/Berlin , er ikke riktig for året 1945 da Trizone brukte andre sommertidregler enn Berlin.

Dekning

Soner som dekker flere land etter 1970

Det er to soner som dekker et område som ble dekket av to land etter 1970. Databasen følger definisjonene av land i henhold til ISO 3166-1 , hvis forgjenger, ISO 3166, ble publisert første gang i 1974.

Vedlikehold

Tz -referansekoden og databasen vedlikeholdes av en gruppe frivillige. Arthur David Olson gjør de fleste endringene i koden, og Paul Eggert i databasen. Foreslåtte endringer sendes til tz -postlisten, som er inngangsport til nyhetsgruppen comp.time.tz Usenet . Kildefiler distribueres via IANA FTP -serveren. Vanligvis blir disse filene tatt av en programvaredistributør som Debian , kompilert, og deretter blir kilden og binærene pakket som en del av denne distribusjonen. Sluttbrukere kan enten stole på programvaredistribusjonens oppdateringsprosedyrer, noe som kan medføre en viss forsinkelse, eller skaffe kilden direkte og bygge de binære filene selv. Den IETF har publisert RFC  6557 , "Prosedyrer for vedlikehold av Time Zone Database" dokumentere beste praksis basert på lignende prinsipper.

Unix-lignende systemer

Standardbanen for tidssonedatabasen er /usr/share/zoneinfo/ i Linux-distribusjoner, macOS og noen andre Unix-lignende systemer.

Bruk og utvidelser

Grenser for tidssoner

Geografiske grenser i form av koordinatsett er ikke en del av tz -databasen, men grenser publiseres av Eric Muller i form av vektorpolygoner. Ved å bruke disse vektorpolygonene kan man for hvert sted på kloden bestemme tz -databasesonen der den befinner seg.

Bruk i andre standarder

Unicode Common Locale Data Repository (CLDR) refererer til soner i tz -databasen. Ettersom navnet på en sone kan endres fra en tz databaseutgivelse til en annen, tilordner CLDR UN/LOCODE for byen som brukes i navnet på sonen, eller en internt tilordnet kode hvis det ikke er en slik by for sone, til en tzdb -sone.

Bruk i programvaresystemer

Tz -databasen brukes til behandling av tidssoner og konverteringer i mange datasystemer, inkludert:

Olson -tidssone -IDene brukes også av Unicode Common Locale Data Repository (CLDR) og International Components for Unicode (ICU). For eksempel kartlegger CLDR Windows - Tzid -tabellen Microsoft Windows tidssone -ID -er til standard Olson -navnene, selv om en slik kartlegging ikke kan være perfekt fordi antall tidssoner i Windows -systemer er betydelig lavere enn de i IANA TZ -databasen.

Historie

Prosjektets opprinnelse går tilbake til 1986 eller tidligere.

Søksmål i 2011

30. september 2011, et søksmål, Astrolabe, Inc. v. Olson et al. , ble arkivert angående opphavsrett i databasen. Som et resultat ble databasens e -postliste og FTP -nettsted stengt 6. oktober 2011 . Saken dreide seg om databasevedligeholdernes bruk av The American Atlas , av Thomas G. Shanks , og The International Atlas , av Thomas G. Shanks og Rique Pottenger. Den klaget over uautorisert gjengivelse av atlasdata i tidssonens e -postliste -arkiv og i noen tilleggslinkesamlinger som vedlikeholdes med databasen, selv om den faktisk ikke pekte på selve databasen. Klagen gjaldt bare sammensetning av historiske tidssonedata, og dekket ikke gjeldende tzdata verden tidssonetabeller.

Dette søksmålet ble løst 22. februar 2012 etter involvering av Electronic Frontier Foundation , da Astrolabe frivillig flyttet til å avvise søksmålet uten å ha tjent de tiltalte og gikk med på en pakt om ikke å saksøke i fremtiden.

Flytt til ICANN

ICANN tok ansvar for vedlikeholdet av databasen 14. oktober 2011. Hele databasen og en beskrivelse av nåværende og fremtidige planer for vedlikehold er tilgjengelig online fra IANA .

Se også

Referanser

Eksterne linker

Generell

Offisielle IANA -kilder

Mann sider

  • zic(8) -  Linux Administration and Privileged Commands Manual (gir syntaks for kildefiler for tz -databasen)
  • tzfile(5) -  Linux filformater Manuell (gir formatet kompilerte tz databasefiler)