Interne Tijd
Intern, een Unix-systeem onderhoudt tijd als het aantal seconden sinds de Unix Epoch. De Unix Epoch werd om middernacht 1 januari 1970 UTC. In de oostelijke tijdzone van de VS was dat 31 december 1969 om 19:00. Terwijl ik dit artikel beginnen, de tijd is 1171733878. Ik gebruik NTP (Network Time Protocol) naar klok van mijn computer te houden in sync. Dus precies op het moment dat mijn computer vond het 1171733878, waarschijnlijk zo ook de jouwe. Elke computer moet worden in overleg met betrekking tot hoe laat het is. Het maakt niet uit in welke tijdzone je computer woont of tijdzone waarin u woont. Als ik had geschreven naar een bestand tijdens deze tweede, zou Unix hebt opgenomen de wijziging tijd als 1171733878.

Unix tijd was van oudsher een ondertekende 32 bit integer. Dat betekent dat de maximale tijd is 2147483647, die in de oostelijke tijdzone van de VS zou 18 januari 2038 ten 22:14:07. Het plan is om deze uit te breiden naar een 64 bit integer voordien. Unix seconden tellen voren een-voor-een. Na 1171733878, de volgende seconde dat mijn systeem zal weten is 1171733879. Zodra is syncronized, NTP werkt door verkorting of verlenging van een seconde. Ik kan de tijd verkrijgen door te bellen naar de system call time (). Als ik wil iets beter dan seconden, de volgende meest accurate interface is de system call tijden (). Keer () voornaamste doel is het verkrijgen van een structuur van gegevens met betrekking tot gebruik van het systeem. Maar de terugkeer code is ook handig ... Het is de tijd in de klok tikt. Klok teken beginnen op een willekeurig punt in het verleden (vaak opstarten) en zij vooraf wanneer de kernel klok routine draait. Hoeveel klok tikken per seconde kan variëren. U kunt bellen sysconf (_SC_CLK_TCK) te komen dat uw waarde. 100 is gemeenschappelijke waarde van deze dagen. Oudere systemen die worden gebruikt 60. 100 en 60 zijn de enige twee waarden die ik heb gezien. Klok teken worden ook als een signed integer. Dus na ongeveer een jaar zal het aantal rollen terug naar nul. Andere dan rollover, klok tikt ook een voorschot-voor-een. (Klok teken worden vaak "jiffies" door Linux mensen.) Er is ook een ander systeem gesprek gettimeofday () die de tijd sinds de Unix Epoch in seconden en microseconden rendementen. gettimeofday () moet bestaan en microseconde nauwkeurig te gebruiken. Echter, de nauwkeurigheid is uitdrukkelijk niet gespecificeerd. De microseconden doen voorschot niet een-voor-een in een systeem dat ik heb gezien. Ik neem aan dat Unix-systemen zijn redelijk goed met hundreths van een tweede en misschien zelfs milliseconden is sommige gevallen. Maar ik zou niet uitgaan enige nauwkeurigheid dan dat.

Human Readable Timestamps
Nu we weten hoe Unix houdt de tijd, laten we gaan naar een ander onderwerp: Hoe de tijd weer te geven aan een gebruiker. Weinig gebruikers zullen blij met een tijdstempel worden weergegeven als 1171733878. Aangezien ik in de oostelijke tijdzone van de VS, zou ik graag zien dat iets 12:37:58 op 17 februari 2007. Maar een persoon in Los Angeles, Californië zou willen dat iets dergelijks 9:37:58 op 17 februari 2007. Ik schreef een beetje perl script om het tijdstip geformatteerd krijgen een nummer als 1171733878. Hier is de output zoals het zou moeten verschijnen in zowel de Oost-en de Stille Oceaan tijdzones voor een paar zorgvuldig geselecteerde timestamps:
Oost:
1173596399 zon 2007-03-11 01:59:59 Standard Time
1173596400 zon 2007-03-11 03:00:00 Daylight Saving Time
1173607199 zon 2007-03-11 05:59:59 Daylight Saving Time
1173607200 zon 2007-03-11 06:00:00 Daylight Saving Time
Pacific:
1173596399 zat 2007-03-10 22:59:59 Standard Time
1173596400 zat 2007-03-10 23:00:00 Standard Time
1173607199 zon 2007-03-11 01:59:59 Standard Time
1173607200 zon 2007-03-11 03:00:00 Daylight Saving Time
Merk op dat de interne Unix tijd heeft geen invloed bij het begin van de Daylight Saving Time. Wat er gebeurt is dat een nieuwe regel voor hoe de tijd weer van kracht wordt. Met het oog op interne tijd om te zetten naar een timestamp, Unix heeft om te weten welke tijdzone te gebruiken. En het moet weten of zomertijd van kracht is. Er zijn verschillende subroutines die kunnen worden opgeroepen voor het opmaken van een tijdstempel. Al deze beroepen uiteindelijk tzset () om de tijdzone en de stand van de zomertijd. En tzset altijd controles voor de omgevingsvariabele TZ te achterhalen wat de gebruiker wil. Als u niet een TZ omgevingsvariabele, tzset () zal gaan met een soort van standaard die kan variëren van systeem tot systeem. De TZ omgevingsvariabele is vaak ingesteld op iets als EST5EDT4 dat is wat ik gebruik. Dit zegt dat ik in een andere tijdzone genoemd EST die wordt gecompenseerd van Universal Time van 5 uur en tijdens zomertijd dag mijn tijdzone heet CEST die wordt gecompenseerd van Universal Time van 4 uur. Om te weten wanneer zomertijd van kracht is, zal tzset blik in enkele gegevens bestand. Welk bestand (en welk formaat het bestand wordt in) varieert van systeem tot systeem. De patches die beschikbaar zijn voor verandering van dit jaar in Zomertijd moet eigenlijk weinig meer dan een aantal herzieningen van deze bestanden.

Universal Time
Naast weten over uw tijdzone, een Unix-systeem moet in staat zijn Universal Time gebruiken (dat is bijna hetzelfde als de oude Greenwich Mean Time). Dit is wat "date-u" doet. De definitie voor Universal Time is bekend en niet gepaard gaat zomertijd veranderingen. De Universal Time definitie kan gebouwd worden in de datum routines in plaats van met behulp van de gegevens bestand voor tzset (). Dit kan waar zijn, zelfs als een item aanwezig is voor de UTC. Mail programma's maken vaak gebruik van UTC timestamps.

Laten we zeggen dat mijn systeem is nog steeds opgezet voor de regel van vorig jaar. Mijn systeem zal binnenkort de verkeerde tijd. Wat moet ik doen? Een ding dat is niet een heel goed idee zou zijn om de klok een uur vooruit handmatig crank. Als ik dat mijn systeem het verkeerde interne tijd zal hebben. Sommige netwerk gebaseerde diensten zoals NFS gebruik van de interne tijd. Mijn systeem zou ook niet langer de juiste Universal Time. NTP (Network Time Protocol) zal storing en klok mijn systeem zal drift. Zelfs voor mijn eigen tijdzone, zou ik graag hebben timestamps 17:00 EST 17:00 CEST wanneer ik zou moeten hebben. Een paar weken later, zal de oude regel van kracht, en ik zal nu moet de klok handmatig weer aan te passen.

Ik hoop dat ik je overtuigd om niet opnieuw de tijd op deze manier. Een betere optie zou zijn om gegevens van mijn systeem onderzoek bestand dat definieert de zomertijd regels voor mijn tijdzone en bewerk het zelf. Dit moet een recht vooruit te veranderen. Maar elk systeem kan zijn eigen formaat.

Er lijkt een bijna universele oplossing: gebruik een meer complexe formaat voor de TZ omgevingsvariabele. Je kunt eigenlijk zet de Daylight Saving regel in TZ en dit gedrag wordt door daartoe Posix. Hieronder is een tabel van de TZ-instellingen die ik denk goed te zijn voor het jaar 2007.

cron zullen reageren op veranderingen in de tijd
Als u het systeem tijd terwijl cron draait aan te passen, zal cron bericht en proberen te compenseren. Als de tijd naar achteren verplaatst, zal cron stoppen banen en wacht tot de klok terug naar voren waar cron de laatste baan. Als de tijd naar voren verplaatst, zal cron proberen te halen. Deze klikt wel elke minuut voortdurend totdat het heeft alle banen gepland tijdens de overgeslagen tijdsduur lopen. Als je gewoon tweaken van het systeem klok, omdat hij uit een paar seconden, is dit perfect. Maar als de tijd is een jaar uitgeschakeld, zal het waarschijnlijk niet een goede zaak. Voor grote aanpassingen van de klok moet je doden en cron herstarten.

cron zullen reageren op Daylight Saving Changes
Stel dat ik een baan hebben gepland om te draaien met 2u15 's morgens zondag. Als we "spring vooruit", zal er geen 2:15. cron zullen er rekening mee dat we 'vooruit afgeveerde "van 60 minuten, dus het 60 minuten zal toevoegen aan mijn werk tijd om 3:15. Het draait de baan op 3:15 ... tenzij de baan al was gepland om te draaien met zowel de 2:15 en 3:15. In dat geval zal mijn werk een keer draaien op 3:15.

Later in het jaar, wij "fall back". Op die zondag zal het 2:15 tweemaal. Mijn taak zal alleen draaien op de eerste 2:15. Als mijn werk heeft een looptijd van 15 minuten na elk uur via het expliciete gebruik van een sterretje in het uur veld mijn werk zal draaien op zowel s. 2u15 ' Dit is niet waar, als ik een bereik gebruiken of een lijst van uren te lopen. Alleen banen met een sterretje voor het uur veld lopen op s. zowel 2u15 '

cron heeft zijn eigen tijdzone
Als ik mijn werk schema voor 2u15 in de ochtend, zal cron draaien wanneer hij denkt dat de tijd is 2:15. cron is nauw verwant aan de "at" commando. Als ik het schema aan baan via "op" om te draaien met 2:15, is mijn variabele TZ geïnspecteerd en de baan zal lopen op mijn 2:15. Maar cron werkt niet op die manier.

De definitie van een seconde wordt zorgvuldig vastgesteld. Elke seconde is precies zo lang als elke andere seconde. Toen wetenschappers waren het vastbinden van de exacte waarde van een tweede, afgestemd ze het zo precies mogelijk aan het jaar 1900. Er zijn 24 * 60 * 60 \u003d 86400 seconden in een dag. Maar de aarde heeft vertraagd een beetje meestal als gevolg van getijdekrachten. Elk jaar moet over ,7 seconden extra. Zo nu en dan hebben we een dag met 86,401 seconden. Unix probeert te doen alsof dit niet het geval is. Als u niet werkt met NTP, dan kunt u periodiek handmatig moet aanpassen uw klok en je zal compenseren voor een schrikkelseconde tijdens uw volgende handmatige aanpassing.

Als u NTP draait, Unix probeert de laatste seconde van de dag te maken met een schrikkelseconde laatste 2 seconden. Met vele implementaties, zal de tweede voorschot ten onrechte in het midden van deze speciale lange tweede en zal terug worden aangepast een paar milliseconden later.

Dus negeren van het potentieel rommelige tweede lange overgangsperiode, behandelen we elke dag alsof het was 86.400 seconden lang.

Door de manier, duurde het ongeveer een eeuw voor de aarde te vertragen genoeg om ,7 seconden extra per jaar nodig. Het duurt nog een eeuw voor te vertragen genoeg tot ongeveer 1,4 seconden nodig extra jaar. Denk niet dat elk jaar wordt ,7 seconden langer dan zijn directe voorganger.

Hier is mijn Perl script dat ik gebruikte in dit artikel ... Dit is hoe ik controleren of de tijdzone gegevens correct zijn. Ik heb net berekenen met de hand de tweede toen ik verwacht dat de Daylight Saving om te schakelen en ik gebruik dit script om te zien of het doet ...

Uw OS grenzen stelt aan het scala aan data die It Can Formaat
U moet de documentatie voor uw systeem om die data kan verwerken.

Bijvoorbeeld, HP-UX 11i Version 2 zegt:
De minimale datum ondersteund door mktime () in zowel 32-bits en 64-bits HP-UX is vrijdag 13 december 20:45:52 UTC 1901. De maximale data ondersteund door mktime () zijn dinsdag 19 januari 03:14:07 UTC 2038 en vrijdag 31 december 23:59:59 UTC 9999 in 32-bits HP-UX en 64-bits HP-UX, respectievelijk. Als de agenda tijd niet kan worden vertegenwoordigd is, de functie geeft de waarde (time_t) -1 en zet errno aan ERANGE. Let op de waarde (time_t) -1 ook overeen met de tijd 23:59:59 op 31 december 1969 (plus of min tijdzone en zomertijd aanpassingen). Zo is het noodzakelijk om zowel de return waarde en controleer errno betrouwbaar te detecteren een fout staat.

Solaris 10 zegt:
De zoneinfo tijdzone gegevensbestanden niet overgang verleden Tue Jan 19 03:14:07 2038 UTC. Daarom is voor 64-bit applicaties met behulp van zoneinfo tijdzones, kan berekeningen na deze datum geen gebruik maken van de juiste compensatie van standaard tijd, en kon retourneren onjuiste waarden. Dit beïnvloedt de 64-bits versie van localtime (), localtime_r (), ctime (), en ctime_r ().

Nanoseconde Resolutie
Ik merk dat Posix is het opgeven van een verscheidenheid van nanaosecond resolutie routines. Ik zie dat Solaris 10 heeft ze uitgevoerd. Ik heb geen ervaring met hen en ik heb ze genegeerd voor deze draad. De clock_settime (3RT) man pagina zegt: Dit impliceert dat de nanoseconde resolutie routines niet bestemd zijn voor tijdwaarneming. Aan de andere kant, zie ik nu een ls-E optie om bestanden weer te geven tijden in nanoseconden.

Als u de tijd in nanoseconden display, zorg ervoor dat je ogen zeer dicht bij het scherm. Licht kan niet reizen zelfs een voet in een nanoseconde.

Verder lezen
Zorg ervoor dat lezen mtime, ctime, en atime voor informatie over de timestamps van bestanden.