Intern Tid
Internt et UNIX-system fastholder tid som antallet af sekunder siden Unix Epoch. Unix Epoch var ved midnatstid 1 januar 1970 UTC. I den østlige tidszone i USA, der var 31 december 1969 kl 19:00. Da jeg i gang med denne artikel, er tiden 1171733878. Jeg bruger NTP (Network Time Protocol) til at holde min computers ur i sync. Så på det præcise øjeblik, at min computer troede, det var 1171733878, formentlig gjorde jeres. Enhver computer skal være enige om, hvad klokken er. Det er ligegyldigt i hvilken tidszone din computer er bosat, eller i hvilken tidszone du bor. Hvis jeg havde skrevet til en fil i samme sekund, ville Unix har registreret ændringen tid som 1171733878.

Unix tid var traditionelt en underskrevet 32 bit heltal. Det betyder, at den maksimale tid er 2147483647 der ville i det østlige TimeZone af den amerikanske være 18 januar 2038 kl 22:14:07. Planen er, at dette at udvide til en 64 bit heltal inden da. Unix sekund tæller frem en ad gangen. Efter 1171733878, at det næste sekund mit system vil vide om, er 1171733879. Når det er synkrone, NTP virker ved at afkorte eller forlænge et sekund. Jeg kan få den tid, ved at kalde systemet vagtperioden (). Hvis jeg vil have noget bedre end sekunder, den næste mest præcise interface er det system, kalder gange (). gange () hovedformål er at opnå en struktur af data om brugen af systemet. Men returkode er også nyttig ... det er den tid på uret flåter. Ur skovflåter starter på et vilkårligt punkt i fortiden (ofte boot tid), og de fremskridt, når kernen uret rutine kører. Hvor mange clock ticks per sekund kan variere. Du kan ringe sysconf (_SC_CLK_TCK) for at finde ud af din værdi. 100 er fælles værdi i disse dage. Ældre systemer, der anvendes 60. 100 og 60 er de eneste to værdier, jeg har set. Ur flåter er også returneres som en underskrevet heltal. Så efter cirka et år, vil antallet rulle tilbage til nul. Andre end rollover, ur tikker også forvejen en efter en. (Clock flåter ofte kaldes "jiffies" af Linux folk.) Der er også et andet system opkald, gettimeofday (), som returnerer gang siden Unix Epoch i sekunder og mikrosekunder. gettimeofday () er forpligtet til at eksistere og at bruge mikrosekund præcision. Men nøjagtigheden er eksplicit uspecificeret. De mikrosekunder sender ikke en ad gangen i ethvert system, som jeg har set. Jeg antager, at Unix-systemer er ret gode med hundrededele af et sekund og måske endda millisekunder er nogle tilfælde. Men jeg vil ikke påtage sig noget præcist ud over dette.

Læses af mennesker timestamps
Nu da vi ved, hvordan Unix holder gang, lad os gå videre til et andet emne: Sådan vises tid til en bruger. Få brugere vil være tilfreds med et tidsstempel, der vises som 1171733878. Da jeg i det østlige tidszone i USA, vil jeg gerne se noget lignende 12:37:58 den 17. Feb, 2007. Men en person i Los Angeles Californien ønsker noget 9:37:58 den 17. Feb, 2007. Jeg skrev en lille perl script til at vise formateret tid, når der gives en række lignende 1171733878. Her er det output som det skal vises i både den østlige og Stillehavet tidszoner for et par omhyggeligt udvalgte timestamps:
Eastern:
1173596399 Sun 2007-03-11 01:59:59 Standard Time
1173596400 Sun 2007-03-11 03:00:00 Sommertid
1173607199 Sun 2007-03-11 05:59:59 Sommertid
1173607200 Sun 2007-03-11 06:00:00 Sommertid
Stillehavet:
1173596399 Sat 2007-03-10 22:59:59 Standard Time
1173596400 Sat 2007-03-10 23:00:00 Standard Time
1173607199 Sun 2007-03-11 01:59:59 Standard Time
1173607200 Sun 2007-03-11 03:00:00 Sommertid
Bemærk, at den interne Unix tid ikke ændrer sig med anfald af sommertid. Hvad der sker, er, at en ny regel for hvordan man kan vise tiden får virkning. For at konvertere interne tid til et tidsstempel, Unix behov for at vide, hvilken tidszone for at bruge. Og det er nødvendigt at vide, om Sommertid er i kraft. Der er forskellige subrutiner, der kan kaldes at formatere et tidsstempel. Alle disse efterhånden påberåbe tzset () for at afgøre den tidszone og staten Sommertid. Og tzset tjekker altid for miljøet variable TZ at finde ud af, hvad brugeren ønsker. Hvis du ikke en TZ miljøvariablen, tzset () vil gå med en form for misligholdelse, der kan variere fra system til system. TZ miljøvariablen er ofte sat til noget EST5EDT4 hvilket er hvad jeg bruger. Denne siger, at jeg i en anden tidszone kaldet EST, der er forskudt fra Universal Time efter 5 timer og i løbet Sommertid dag min tidszone kaldes EDT, der er forskudt fra Universal Time med 4 timer. At vide, hvornår Sommertid er i kraft, vil tzset kigge i nogle data fil. Hvilken fil (og hvilket format filen er i) er forskellig fra system til system. De rettelser, der er til rådighed for dette års ændring i sommertid bør virkelig være lidt mere end nogle ændringer til disse filer.

Universal Time
Ud over at vide om din tidszone, en Unix-system skal være i stand til at bruge Universal Time (hvilket er næsten det samme som den gamle Greenwich Mean Time). Dette er, hvad "date-u" gør. Definitionen for Universal Time er velkendt og ikke indebærer sommertid ændringer. The Universal Time definition kan bygge ind datoen rutiner frem for at bruge de data fil til tzset (). Dette kan være tilfældet, selvom en løsning er til stede for UTC. Mail-programmer ofte bruger UTC timestamps.

Lad os sige at mit system er stadig sat op til sidste års reglen. Mit system vil snart vise det forkerte tidspunkt. Hvad skal jeg gøre? En ting, der er ikke en meget god idé ville være at krank uret en time frem manuelt. Hvis jeg gør, at mit system vil have den forkerte interne tid. Nogle net-baserede tjenester såsom NFS bruge den interne tid. Mit system vil heller ikke længere har den korrekte Universal Time. NTP (Network Time Protocol) vil fejl og min systemets ur vil glide. Selv for min egen tidszone, ville jeg have tidsstempler gerne 17:00 EST, når jeg skulle have 17:00 EDT. Et par uger senere, vil den gamle regel i kraft, og jeg vil nu nødt til at justere uret manuelt igen.

Jeg håber, at jeg er overbevist om, at du ikke nulstille tiden på denne måde. En bedre løsning ville være at forskning mit system's data-fil, der definerer sommertid regler for min tidszone og redigere det selv. Dette bør være en straight forward forandring. Men hvert system kan have sit eget format.

Der synes at være en næsten universel løsning: brug en mere kompleks format for TZ miljøvariablen. Du kan faktisk sætte Sommertid regel i TZ og denne opførsel har mandat fra POSIX. Nedenfor er en oversigt over TZ indstillinger, som jeg mener er rigtige for året 2007.

Cron vil reagere på ændringer i Time
Hvis du justerer systemet tid, mens cron kører, vil cron varsel og forsøge at kompensere. Hvis tiden flyttet tilbage, vil cron standse job og vente på uret til forskud tilbage, hvor cron køre det sidste job. Hvis tiden går fremad, vil cron forsøge at indhente det forsømte. Det vil klikke selvom hvert minut uafbrudt, indtil det har kørt alle de arbejdspladser planlagt i løbet af de springes over tid varighed. Hvis du er simpelthen tweaking systemet ur, fordi det var slukket et par sekunder, det er perfekt. Men hvis tiden er et års pause, vil det sandsynligvis ikke være en god ting. For store justeringer af uret, skal du dræbe og genstarte cron.

cron vil reagere på Daylight Saving Changes
Antag at jeg har et job planlagt til at køre på 2:15 søndag morgen. Når vi "spring fremad", vil der ikke være 2:15. Cron vil bemærke, at vi "sprunget ahead" 60 minutter, så det vil tilsættes 60 minutter til mit job time getting 3:15. Det vil køre jobbet på 3:15 ... medmindre jobbet allerede var planlagt til at køre på både 2:15 og 3:15. I så fald vil mit job køre én gang på 3:15.

Senere på året, vi "falde tilbage". På denne søndag, vil det være 2:15 to gange. Mit job vil kun køre på det første 2:15. Hvis mit arbejde er planlagt til at løbe på 15 minutter efter hver time via den eksplicitte brug af en stjerne i timen på mit job, der kan køre både på 2:15 's. Dette er ikke sandt, hvis jeg bruger et område eller en liste af timer at køre. Kun jobs med en stjerne for timen feltet køre både på 2:15 's.

cron har sin egen tidszone
Hvis jeg planlægge mit job for 2:15 om morgenen, vil cron køre den, når den mener, at tiden er 2:15. cron er tæt forbundet med "at" kommando. Hvis jeg ofte på job via "ved" at køre på 2:15, min TZ variabel er inspiceret og jobbet vil køre på min 2:15. Men cron virker ikke på den måde.

Definitionen af en anden er omhyggeligt fast. Hvert sekund er præcis så længe som alle andre sekund. Når forskere var binde den præcise værdi af et sekund, de handler det så nøjagtigt som muligt til år 1900. Der er 24 * 60 * 60 \u003d 86400 sekunder i en dag. Men jorden er faldet en smule primært på grund af tidevand kræfter. Hvert år den har brug for ca ,7 sekunder ekstra. Hver dag og så har vi en dag med 86401 sekunder. Unix forsøger at foregive, at dette ikke er tilfældet. Hvis du ikke kører NTP, skal du med jævne mellemrum manuelt justere dit ur, og du vil kompensere for et spring i sekundet under din næste manuel justering.

Hvis du kører NTP, Unix forsøger at gøre det sidste sekund af dagen med et spring næstsidste i 2 sekunder. Med mange implementeringer, vil den anden upassende forskud i midten af denne særlige lange sekunder, og vil blive justeret baglæns et par millisekunder senere.

Så ignorerer de potentielle rodet anden lange overgangsperioder, vi behandler hver dag, som om det var 86400 sekunder lang.

Af den måde, tog det omkring et århundrede, for Jorden at bremse nok til behovet ,7 sekunder ekstra hvert år. Det vil tage et andet århundrede til at falde nok til at have omkring 1,4 sekunder ekstra år. Tror ikke, at der hvert år er ,7 sekunder længere end dens umiddelbare forgænger.

Her er mit Perl skrift, at jeg brugte i denne artikel ... Dette er, hvordan jeg kontrollere, at den tidszone data er korrekte. Jeg har lige beregne i hånden den anden, da jeg forventer, at sommertid til at skifte, og jeg bruger dette script til at se, om det ikke ...

Dit OS, begrænser datointerval, at det kan Format
Du skal tjekke dokumentationen til dit system, som datoer det kan håndtere.

For eksempel, siger HP-UX 11i Version 2:
Den mindste dato støttet af mktime () i både 32-bit og 64-bit HP-UX er fredag December 13 20:45:52 UTC 1901. Den maksimale datoer, der støttes af mktime () er tirsdag 19 januar 03:14:07 UTC 2038 og fredag December 31 23:59:59 UTC 9.999 i 32-bit HP-UX og 64-bit HP-UX, hhv. Hvis kalenderen tid ikke kan være repræsenteret, funktionen returnerer værdien (time_t) -1 og sæt errno til ERANGE. Bemærk værdien (time_t) -1 svarer også til den tid, 23:59:59 den 31. Dec, 1969 (plus eller minus tidszone og sommertid justeringer). Derfor er det nødvendigt at kontrollere både den returværdi og errno til pålideligt opdage en fejl.

Solaris 10 siger:
Den zoneinfo tidszone datafiler ikke overgangen tidligere Tue Jan 19 03:14:07 2038 UTC. Derfor til 64-bit-programmer ved hjælp zoneinfo tidszoner, kan beregningerne efter denne dato ikke bruge den korrekte offset fra standard tid, og kan returnere forkerte værdier. Dette påvirker 64-bit version af localtime (), localtime_r (), ctime (), og ctime_r ().

Nanosekund resolution
Jeg bemærker, at POSIX specificerer en række nanaosecond beslutning rutiner. Jeg kan se, at Solaris 10 har gennemført dem. Jeg har ingen erfaring med dem, og jeg har ignoreret dem til denne tråd. Den clock_settime (3RT) man-siden siger: Dette indebærer, at nanosekund beslutning rutiner ikke er beregnet til tidtagning. På den anden side ser jeg ls nu har en-E for at vise filen gange i nanosekunder.

Hvis du viser tiden i nanosekunder, skal du sørge for at holde dine øjne meget tæt på skærmen. Lyset kan ikke rejse selv et fuldstændigt fod i et nanosekund.

Læs mere
Vær sikker på at læse mtime, ctime, og atime for oplysninger om tidsstempler af filer.