Den tid Unix eller tids POSIX (også kalt Unix tidsstempel ) er et mål på tid basert på antall sekunder siden1 st januar 197000:00:00 UTC , unntatt skuddsekunder . Den brukes hovedsakelig i systemer som overholder POSIX- standarden , inkludert Unix-lignende systemer , derav navnet. Det er POSIX-representasjonen av tid.
For å knytte en hendelse til et reelt tall, er det tilstrekkelig å bruke naturlige og universelle referanser: for eksempel jordens rotasjonsperioder på seg selv og rundt solen. Disse periodene er tilstrekkelig til å etablere kalendere , det vil si forholdet mellom hendelser og datoer, selv om det er nødvendig med en viss innsats for å tydelig definere referansene som brukes (hvert land har sitt eget, alt vedtatt på forskjellige tidspunkter.); datoene for disse kalenderne er bare tall uttrykt i et noe komplisert nummereringssystem som har enhetene dag, uke, måned, årstid, år osv., og Posix-tiden er ikke en referanse blant annet uttrykt som et enkelt tall.
Hovedmålesystemer bruktHer er de viktigste tidsmålesystemene som har blitt forestilt og brukt til i dag:
Forkortelse | Betydning | Definisjon |
---|---|---|
GMT | Greenwich Mean Time | Fortsatt i bruk i noen land for juridiske aspekter.
Definisjonen av dette målesystemet er imidlertid tvetydig. Dette er grunnen til at det, bortsett fra denne administrative bruken, er å foretrekke å bruke UTC. |
Ut | Universell tid | Dette systemet definerer dagen som den gjennomsnittlige varigheten av jordens rotasjon rundt sin akse.
Denne definisjonen gir noen vanskeligheter fordi hastigheten på denne rotasjonen ikke er konstant, den avtar sakte under tidevannets virkning og gir dessuten uforutsigbare uregelmessigheter: varigheten av dagene UT er i gjennomsnitt veldig litt større enn 86.400 sekunder ( antall sekunder på 24 timer). Forskjellen er i størrelsesorden et sekund over ett til tre år. Det er flere versjoner av UT: UT0, UT1, UT1R, UT2. Se artikkelen " Universell tid " for mer informasjon. |
TAI | Internasjonal atomtid | Dette systemet er basert på en internasjonal definisjon av det andre. Standarden består av flere atomur distribuert over hele verden. Måling av tid i dette systemet er strengt regelmessig i motsetning til den forrige som standarden ikke har samme regelmessighet for. Som et resultat beveger TAI og UT seg gradvis vekk fra hverandre på grunn av det andre.
|
UTC | Koordinert universell tid |
Dette systemet er vedtatt som grunnlag for internasjonal sivil tid av et stort antall land. Ordet "koordinert" indikerer at:
Med andre ord, UTC er identisk med TAI (den har sin stabilitet og nøyaktighet) ned til et helt antall sekunder, noe som gjør at den kan holde seg til UT til nærmeste 0,9 s ; dette er hva figuren motsatt viser.
|
For å måle tid, må du velge en opprinnelse:
Det er nødvendig å indikere hvordan dette tallet utvikler seg etter tidens gang:
# | TAI | UTC | TAI - UTC | Posix tid | |
---|---|---|---|---|---|
1 | 2009-01-01T00: 00: 30 | 2008-12-31T23: 59: 57 | 33 | 1.230.767.997 | |
2 | 2009-01-01T00: 00: 31 | 2008-12-31T23: 59: 58 | 33 | 1.230.767.998 | |
3 | 2009-01-01T00: 00: 32 | 2008-12-31T23: 59: 59 | 33 | 1.230.767.999 | |
4 | 2009-01-01T00: 00: 33 | 2008-12-31T23: 59: 60 | 33 | 1.230.768.000 | tillegg av et sprang sekund |
5 | 2009-01-01T00: 00: 34 | 2009-01-01T00: 00: 00 | 34 | 1.230.768.000 | |
6 | 2009-01-01T00: 00: 35 | 2009-01-01T00: 00: 01 | 34 | 1.230.768.001 | |
7 | 2009-01-01T00: 00: 36 | 2009-01-01T00: 00: 02 | 34 | 1.230.768.002 |
Posix Time er ikke en lineær fremstilling av tid, det er anomalier, som rad 5 i tabellen ovenfor.
Ingen korrespondanse bijective mellom UTC og POSIX tid; sistnevnte tillater ikke å representere sprangsekundene som er tilstede i UTC, som linje 4 i tabellen ovenfor: 2008-12-31T23: 59: 60 UTC.
Disse forskjellige referansene skal ikke blandes sammen (for eksempel begynner år null på en kalender ikke samtidig med en annen), og også fordi alle disse kalenderne må tilpasse seg perioder som ikke er flere. For eksempel fra hverandre, for eksempel skuddår, eller uregelmessighetene i disse periodene. Disse tilpasningene kompliserer beregningene litt, avhengig av presisjonen du leter etter; for eksempel kan det ha gått et år som er tilstrekkelig informasjon, eller det vil være nødvendig å ta hensyn til årets sprangkarakter for å svare på det samme spørsmålet uttrykt i antall dager. Dette betyr at du må beholde et minne fra fortiden, minnet om hvert sekund som går.
I de fleste tilfeller er en enkel forskjell i Posix-tidene tilstrekkelig, med mindre de to hendelsene strekker seg over ett eller flere sprangsekunder. For å beregne en nøyaktig forsinkelse under alle omstendigheter, må du ta sprangsekundene i betraktning.
Forekomsten av sprangsekunder er imidlertid lav, så sannsynligheten for å begå en slik feil er lav; og hvis saken til tross for alt skjer, kan feilens størrelse være liten, og det er ikke nødvendig å bekymre seg for de sprangsekundene i dette tilfellet; tabellen nedenfor viser forskjellige eksempler.
Metoden for å fullføre en rad i denne tabellen er som følger:
Å bruke denne metoden for ganger M = 10, 100, 1000 gir følgende tabell:
Tid til å måle (M) | Sannsynlighet for feil | Feilens størrelse |
---|---|---|
10 s | 3,2 × 10-7 | 10% |
100 s | 3,2 × 10-6 | 1% |
1000 s | 3,2 × 10 -5 | 0,1% |
Til slutt, hvis tiden til å beregne mellom de to hendelsene av interesse er ett år, er sannsynligheten 100% for å gjøre en feil på 3,2 × 10-8 .
Sannsynligheten for å begå en gitt feil og størrelsen på denne feilen varierer omvendt med hverandre. en annen måte å si det kan være å si:
Hvis dette paret (sannsynligheten for å gjøre en feil / størrelsen på feilen) er uakseptabelt, eller hvis vi ikke vet hvordan vi skal evaluere virkningen, er det absolutt nødvendig å stille spørsmålet om hvorfor vi bruker UTC og hva er behovet for nødvendig presisjon, eller for å sørge for at bruk av tabeller skal oppdateres så snart innsetting / fjerning av et skuddsekund er programmert.
Konvertering av UTC til Posix TimeBortsett fra de svært sjeldne anomaliene som er nevnt ovenfor angående sprangsekunder, er det enkelt å konvertere en UTC-tid til en Posix-tid og omvendt.
Eksempel: Hva er Posix-tiden helt på dagen 1 st januar 2009(rad 5 i tabell 1 ovenfor):
Antall dager som har gått | ||||
---|---|---|---|---|
1.970 | 1 971 | 1 972 | 1 973 | 3 * 365 + 366 = 1461 |
1.974 | 1 975 | 1 976 | 1 977 | 1461 |
1 978 | 1 979 | 1 980 | nitten åtti en | 1461 |
1 982 | 1 983 | 1 984 | 1 985 | 1461 |
1.986 | 1 987 | 1 988 | 1 989 | 1461 |
1990 | 1.991 | 1.992 | 1.993 | 1461 |
1 994 | 1.995 | 1.996 | 1997 | 1461 |
1.998 | 1.999 | 2.000 | 2.001 | 1461 |
2.002 | 2.003 | 2004 | 2.005 | 1461 |
2.006 | 2.007 | 2.008 | 2 * 365 + 366 = 1096 | |
14 245 |
Det er også verktøy som utfører disse beregningene veldig enkelt, for eksempel dette "skallskriptet" for å konvertere et antall sekunder siden Posix-tiden til en dato:
#!/bin/sh # convertir un nombre de secondes depuis l'époque Posix # en date # exemple: date -u -R --date "1970-01-01 1230768000 seconds" date -u -R --date "1970-01-01 $* seconds" Konvertering av en Posix-tid til UTC-tidDen omvendte beregningen gir ingen problemer, og på samme måte er det verktøy som utfører disse beregningene veldig enkelt, som dette bash-skriptet for å konvertere en dato til et antall sekunder siden Posix-epoken:
#!/bin/sh # convertir une date (attention au format de l'argument) # en nombre de secondes depuis l'époque Posix # exemple: date --date "2009-01-01 00:00:00+00:00" "+%s" date --date "$*" "+%s"Den vanligste metoden for å lese tiden under Unix er anropet til følgende funksjon som returnerer en numerisk verdi av typen " time_t".
time_t time(NULL);Denne typen time_t brukes ofte til å manipulere UNIX-tiden, dessverre spesifiserer ikke POSIX-standarden (tydelig) størrelsen:
Unix-tid | UTC | |
---|---|---|
tidligste dato: -2 31 | −2 147 483 648 | 1901-12-13 T 20:45:52 |
Unix era: 0 | 0 | 1970-01-01 T 00:00:00 |
tidligste dato: 2 31 -1 | 2.147.483.647 | 2038-01-19 T 03:14:07 |
Denne umuligheten av representasjon setter ikke nødvendigvis spørsmålstegn ved selve driften av maskinen, det vil si driften av operativsystemet, men driften av applikasjonene og dens interoperabilitet med andre maskiner. Det er faktisk ikke nok for en maskin å vite hvordan den skal håndtere denne grensen lokalt, men det er også nødvendig at alle maskinene som er koblet til den er i stand til å håndtere denne grensen og dette på samme måte.
Flere saker kan oppstå:
Unix-systemer har vanligvis en teller hvis oppløsning er finere enn den andre. Denne tiden kan nås ved å ringe til følgende funksjon:
int gettimeofday(struct timeval *tv, NULL);Den numeriske verdien som returneres av denne funksjonen, lagres i variabelen “ struct timeval *tv ” som er definert som følger:
struct timeval { int tv_sec; /* secondes */ int tv_usec; /* microsecondes de 0 à 999999 */ };Ved å bruke denne undersekvensoppløsningen blir det spørsmålet om hva som skjer når et skuddsekund legges til eller trekkes fra? Det ser ut til at dette punktet er operativsystemets ansvar. I mangel av en klar spesifikasjon er det derfor mulig med flere scenarier, avhengig av hvilket operativsystem som vurderes. De tre eksemplene nedenfor viser de tre kategoriene av saker som virker mest representative, de handler bare om innsettingsaspektet av et skuddsekund, men de kan lett tilpasses tilfellet med sletting:
# | UTC | tv_sec | tv_usec | |
---|---|---|---|---|
4 | 2008-12-31T23: 59: 60.000 | 1.230.768.000 | 0 | |
2008-12-31T23: 59: 60.500 | 1.230.768.000 | 500.000 | ||
5 | 2009-01-01T00: 00: 00.000 | 1.230.768.000 | 0 | tiden plutselig justert |
2009-01-01T00: 00: 00.500 | 1.230.768.000 | 500.000 | ||
6 | 2009-01-01T00: 00: 01.000 | 1.230.768.001 | 0 |
# | UTC | tv_sec | tv_usec | |
---|---|---|---|---|
4 | 2008-12-31T23: 59: 60.000 | 1.230.768.000 | 0 | |
2008-12-31T23: 59: 60.500 | 1.230.768.000 | 0 | frossen time | |
5 | 2009-01-01T00: 00: 00.000 | 1.230.768.000 | 0 | frossen time |
2009-01-01T00: 00: 00.500 | 1.230.768.000 | 500.000 | ||
6 | 2009-01-01T00: 00: 01.000 | 1.230.768.001 | 0 |
# | UTC | tv_sec | tv_usec | |
---|---|---|---|---|
4 | 2008-12-31T23: 59: 60.000 | 1.230.768.000 | 0 | |
2008-12-31T23: 59: 60.500 | 1.230.768.000 | 250.000 | senket tiden | |
5 | 2009-01-01T00: 00: 00.000 | 1.230.768.000 | 500.000 | senket tiden |
2009-01-01T00: 00: 00.500 | 1.230.768.000 | 750.000 | senket tiden | |
6 | 2009-01-01T00: 00: 01.000 | 1.230.768.001 | 0 |
Ideen om å bruke internasjonal atomtid har allerede blitt foreslått og forsvart av mange mennesker, men dette er ikke meningen gitt av historien, det valgte valget var det som i dag er frosset av POSIX-standarden.
Daniel J. Bernstein har også skrevet artikler og programvare for bruk av TAI på UNIX-lignende systemer.
Unix gigasekund refererer til Unix time 10 9 , som representerer9. september 2001.