1234567890 FEST!

Engang hvor dot-com stadig var en levende drøm, holdt DKUUG, på undertegnedes oplæg, en fest for at fejre at det var 1 mia sekunder siden at UNIX begyndte.

Det var en fest der ville noget.

I nat er det blot en numerisk seværdighed:

critter phk> date -r 1234567890
Sat Feb 14 00:31:30 CET 2009

Men hey, hvor meget undskyldning skal man egentlig bruge for at feste ?

phk

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Andreas Bach Aaen

Fejringen af 1 mia. sekunder siden Unix-urets begyndelse var en ganske særligblanding af konference og fest. Af alle steder i verden valgte a at fejre det i Danmark. i Danark faldt tidspunktet omkring klokken 3 om natten. Jeg mener endda, at det var lykkedes at skaffe Rob Pike - en af Unixens forfædre - til Danmark. Lidt op i årene, jetlag og så oppe til klokken 3 m natten. Lidt af en præstation.
Som konferene var det genialt. Som ved alle gode konferener, så sker det virkeligt spændende i korridorerne. Når nu alle skulle holde sig vågne til sent om natten, så var der rigeligt med tid til korridorsnak - og det endda uden, at man behøvede at droppe foredragene om eftermiddagen/aftenen.
Som fest husker jeg uptime(1) mest som et band, der var istand til at støje så meget, at de ikke ænsede om der var publikum eller ej.

  • 0
  • 0
Poul-Henning Kamp Blogger

Mnjae, nu er det (eneste) geniale ved UNIX' time_t netop at den ikke afhænger af den lokale tid, men derimod tæller i UTC tid.

Derfor oprandt de 10^9 sekunder på samme tid over hele verden.

Men ja, det var en kanon fest og det der band var alt for larmende, men der var heldigvis en masse andet at lave.

Poul-Henning

  • 0
  • 0
Peter Brodersen

Lidt på linje med PHKs festbetragtninger er jeg ikke helt med på, hvorfor jeg nu prøver at tale mig ud af en anledning til at feste.

Men idet unix time ikke medtager skudsekunder, så var der kl. 00:30 i Danmark ikke gået 1234567890 sekunder siden epoch.

I første omgang kan det virke som talmagi-pedanteri på linje med halvligegyldige år 2000-diskussionen om "årtusindeskifte" (og i samme forbindelse om det overhovedet var et årtusindeskifte eller bare et "pænt, rundt tal", man mente at man fejrede).

Men der er to væsentlige pointer:

  1. unix time er ikke et lineært offset. Det betyder fx at der mellem 1230767999 og 1230767999+2 er forløbet tre sekunder. I langt de fleste tilfælde kan vi være ligeglade, fordi vi foretrækker at bruge koncepter som fx minutter, time, dage, måneder og år, der netop godt må variere i størrelse.

Men hvis man vil lave beregninger i sekunder (som i tid, i modsætning til koncepter), så kan det være farligt at benytte unix time som en del af ens struktur. Idet vi også kan finmaske unix time under et sekund, risikerer vi to (i tid) efterfølgende observationer, hvor anden observation har et lavere unix time point end det første, fx hhv. 1230768000.75 og 1230768000.25 et halvt sekund senere.

Idet unix time således er et datoformat, bør man håndtere det som dette. Hvilket fører os til andet problem:

  1. unix time er et nærved-og-næsten-format

Det ligner et offset. Det opfører sig for det meste af siden som et offset. Derfor er det fristende at benytte sig af aritmetik direkte på unix time points, fx at trække to værdier fra hinanden og efterfølgende antage, at man har forskellen (i tid).

Mange protokoller arbejder som udgangspunkt i rent tekst, hvilket gør, at man også her kan falde for fristelsen til at fyre kommandoer direkte af, i stedet for at bruge et passende bibliotek til håndtering heraf. Jeg har oplevet en del udviklere i tidens løs, som selv skruede deres HTTP-requests sammen, fordi "det var let". Men med masser af latente fejl som følge. Én af de mest udbredte har været opfattelsen af at idet det dér internet jo er noget unix-noget, så skal man også bruge unix-linjeskift (0x0a) i sine requests - selv om HTTP, FTP, NNTP, SMTP, POP3, IMAP4, etc. alle bruger 0x0d 0x0a som linjeskift.

Så i stedet for at tænke på formater og protokoller, så bliver det bare betragtet som tal og tekst, med den efterfølgende fejlslutning, at det kan man jo arbejde direkte på uden at skulle bruge noget library til formålet.

Givet, det vil virke størstedelen af tiden, lige indtil det særtilfælde (som måske aldrig opstår i praksis), hvor det ikke virker. Det samme kan siges om race conditions og manglende transaktionshåndtering, hvor det er relevant.

Men fordi det lugter af at være noget, folk direkte kan arbejde på, så er risikoen tilsvarende større for at folk vil gøre det.

Unix time er tilpasset datoformater, fordi det er det, der er praktisk for os. Men hvis det alligevel er et datoformat, så giver det for mig oftere mening at bruge ét, hvor syntaksen ligger tættere op ad, hvad det skal repræsentere. Det er mere klart med vores datoopfattelse, at fx 2009-01-01 er et døgn efter 2008-12-31, end at 86400 repræsenterer et døgn og ikke (nødvendigvis) 86400 sekunder.

  • 0
  • 0
Poul-Henning Kamp Blogger

Men idet unix time ikke medtager skudsekunder, så var der kl. 00:30 i Danmark ikke gået 1234567890 sekunder siden epoch.

Jo, det var der indiskutabelt, der er ingen tvivl om at time_t har talt præcist 1234567890 sekunder siden 1970-01-01 00:00:00Z ifølge dens meget præcise (men delvist virklighedsfjerne) definition.

Men der var IKKE gået 1234567890 UTC sekunder siden 1970-01-01 00:00:00Z.

Faktisk var der ikke engang gået et helt antal UTC sekunder, for indtil 1972-01-01 00:00:00Z var der stadig tale om de gamle "gummisekunder" hvor sekundets længde blev justeret efter jordens rotation.

Så ud over skudsekunderne, er der 82 microsekunder der også skal gøres rede for.

Poul-Henning

  • 0
  • 0
Anonym

Kommer bare til at tænke på et andet datoformat.
Juliandate, som det vistnok hed inden for HP regi.

Det var fra dengang hvor diskplads kostede spidsen af en jetjager, og man skulle spare på bittene (en 120MB disk kostede 1/4 mio).

Så en dato kunne/kan angives med 7 bits til årstal, og resterende bits til dag i året.

7 bits rækker til (1900 + 127 ), så mon ikke der kunne dukke (endnu et) 'problem op i 2027 ?

(For en god ordens skyld, så dem der har 'rodet' med 20-årige obligationer/pantebreve kendte nok til Y2K og deraf følgende FUD)

Og når vi snakker Y2K, og ast folk tilsyneladende var dumme, så har jeg selv været med til at implemente et (potentielt) Y2K problem.

Spørgsmålet:
Skal vi Y2K sikre det?

Beslutningsgrundlaget:
At sikre: Jo, det kan vi godt, men det koster 576.000,- ekstra i diskplads (anno 1985-1986)
At lade være med at sikre: Helt ærligt - beslutningstager - denne software er da garenteret fornyet/erstattet inden for de næste 15 år!

Ja, ja, ævle - men hold øje med 2027!

  • 0
  • 0
Hans Schou

At lade være med at sikre: Helt ærligt - beslutningstager - denne software er da garenteret fornyet/erstattet inden for de næste 15 år!

Ja, ja, ævle - men hold øje med 2027!

Hvis det er HP-UX hvor denne Julian date optræder, så er mit gæt at der ikke er noget problem i 2027.

Men mon ikke der er en eller andet tosset embeded device der har et problem i 2038?

Nå hva', det kan vel næppe blive til mere end et par bebrejdene blikke fra børnebørnene...

  • 0
  • 0
Anonym

Hvis det er HP-UX hvor denne Julian date optræder

Det var nu MPE, og ikke RTE/UX.

Jeg kom bare i tanke om dengang alle folk frygtede Y2K(FUD), og ikke kendte begrundelsen for visse beslutninger, men mente at udviklerne var 'for dumme'.

I dagens danmark er der ikke behov(økonomi) i at holde datoer i 16 bits frem for 32(+) bits, men det var en betydende faktor da lagerplads kostede (mange) penge.

  • 0
  • 0
Log ind eller Opret konto for at kommentere