Hvorfor er det nu jeg kommer til at tænke på den gamle historie om at hvis vi byggede huse som vi programmerer, ville den første spætte, der kom forbi, ødelægge civilisationen :-)

Skudsekundet giver aabenbart problemer for computere. Hvorfor kan man ikke blive enige om en fælles tidsregning uden skudsekunder indenfor computerverdenen? Hvis man fik denne enighed ville systemet med skudsekunder sikkert blive udfaset over en aarrække og tilsidst blive betragtet som kuriositet.

Skudsekundet giver aabenbart problemer for computere. Hvorfor kan man ikke blive enige om en fælles tidsregning uden skudsekunder indenfor computerverdenen?

Fordi (visse) astronomer insisterer på at have en rolle i tidsregning.

http://queue.acm.org/detail.cfm?id=1967009

Her kan man læse hvilke problemer skudsekundet gav LHC (Slide 9):

http://lhc-commissioning.web.cern.ch/lhc-c...

Det er endda efter min opfattelse relativt hurtigt at det kun tog 3 timer at komme tilbage online. Desuden er de heldige, at skudsekundet faldt lige efter et planlagt servicevindue, således at det ikke berørte 'produktionen'

Ja, skudsekundet er en dum ide!

Man kunne lave en lukketid for internettet. At vi skal undvære el og internet i 5 min, ser jeg ikke som et problem.

Man kunne lave en lukketid for internettet. At vi skal undvære el og internet i 5 min, ser jeg ikke som et problem.

Jeg er ikke sikker på at de pårørende til en patient på intensiv er tilfredse med den løsning.
Desuden kan man ikke lukke for el nettet i 5 min, en black start af el-nettet tager nogle timer.

Der er kun en løsning på dette, få NTP til at distribuere TAI i stedet for UTC.
Og indfør et opdateret OS API til at hente TAI, hvilket betyder at (nyt) software kan håndtere skud sekunder på samme måde som sommertid. (Lagere tidsstempler i TAI, og konverter dem til lokaltid på præsentations tidspunkt).

Hejsa

Er det ikke muligt at håndterer det, med et SW tiltag
den var også gal ved DMI

http://www.dmi.dk/dmi/skudsekund_sarede_se...

hilsen svend-ev

Der er kun en løsning på dette, få NTP til at distribuere TAI i stedet for UTC. Og indfør et opdateret OS API til at hente TAI, hvilket betyder at (nyt) software kan håndtere skud sekunder på samme måde som sommertid. (Lagere tidsstempler i TAI, og konverter dem til lokaltid på præsentations tidspunkt).

Løsningen du beskriver kunne også kaldes "lad fysikerne styre tiden og smid astronomerne ud". Der er også en anden korrekt løsning, "lad astronomerne styre tiden og smid fysikerne ud". Den indebærer at man varierer længden af sekundet så der altid er 86400 sekunder i et døgn. Det betyder så at man ikke længere kan benytte atomure til tidsservere, men derimod skal bruge astronomiske observatorier. (Det har også den lille ulempe at meter ikke er lige lange alle dage, men det kan man definere sig ud af...)

Løsningen er korrekt og rimeligt uproblematisk for computere; deres indbyggede ure er som hovedregel så elendige at de har behov for konstant hjælp udefra i form af f.eks. NTP. Variationen i sekundlængde vil ligge langt indenfor den naturlige variation i urene, f.eks. på grund af skiftende temperatur. Typisk vil justeringen være omkring en hundrededel sekund pr dag, eller ca. 0,1ppm. Løsningen vil også virke om 100,000 år, hvilket hverken skudsekunder eller skudtimer gør.

Det er naturligvis en elendig løsning for fysikerne og heller ikke fantastisk sjov for computere, men dog langt bedre end det vi har i dag.

Kan vi ikke lave en eller anden form for duel mellem fysikerne og astronomerne? Uanset hvem der vinder er det bedre end det nuværende elendige kompromis.

Niels Danielsen:

Jeg er ikke sikker på at de pårørende til en patient på intensiv er tilfredse med den løsning.

Du er vist ikke klar over, hvor mange huller i IT-driften man ser på intensive afdelinger. Fem minutter ville næppe blive bemærket sammenlignet med, hvad man ellers ser. Lad os nu først se programmer, som kører godt, når de er i drift.

Mht. til el slår man jo i forvejen over på nøddrift en gang om ugen.

Du er vist ikke klar over, hvor mange huller i IT-driften man ser på intensive afdelinger.

Se også: http://www.economist.com/blogs/babbage/201...

Se også: http://www.economist.com/blogs/babbage/201...

• yiiiirk, det vist godt det ikke kun var teknik der overvågede een på intensiv, men at der også var et dedikeret personale - tak for det.
  /OT

Hvorfor er det nu jeg kommer til at tænke på den gamle historie om at hvis vi byggede huse som vi programmerer, ville den første spætte, der kom forbi, ødelægge civilisationen :-)

Ja, og nu fik vi endnu engang set, hvilke operativsystemer, man skal holde sig fra, hvis man ønsker en stabil drift. Skudsekundproblemet har været kendt i årevis; men nogle systemer er åbenbart så håbløst skruet sammen, at ingen tør eller magter at stikke hånden ned i hvepsereden og prøve at rette selv de mest basale fejl. Så hellere lave nat om til dag på langt sigt.

År 2000 problemet skyldtes udelukkende dårlige programmører, som ikke kunne indse, at hvis man beregnede sig frem til en dato mange år før programmet var skrevet og computeren i det hele taget var opfundet, kunne det måske være hensigtsmæssigt at lægge 100 til årstallet.

Skudsekunder, Polsag, Amanda, IC4 etc. etc. Ak ja. Vore dages programmører har intet lært.

Så i mener at opfindere skal forudse alle tænkelige problematikker inden de lancerer deres opfindelse?

Så i mener at opfindere skal forudse alle tænkelige problematikker inden de lancerer deres opfindelse?

Nej, men skudsekundproblemet har været kendt siden Juli 1972, hvor det første skudsekundt blev indført, så der er ingen undskyldning for programmer skrevet siden da - heller ikke for UNIX, der først blev officielt kendt 2 år senere.

Der er nu indsat 25 skudsekunder, og fejlen er stadig ikke rettet. Mon ikke der er nogle, der er ualmindelig træge i optrækket?

vi kører jo også stadig i benzindrevne biler.

vi kører jo også stadig i benzindrevne biler.

Ja, for har du et bedre alternativ til kortere ture, hvor en dieselmotor ikke kan nå at blive ordentlig varm - og vel at mærke en løsning, som samtidig tillader lange ture?

næ, men jeg ville da heller ikke stå i vejen hvis der viser sig en genial løsning. men heller ikke udelukke at jeg finder det interessant at benytte systemer på trods af kendte indbyggede fejl. fejlen må jo opvejes i forhold til hvad man får ved siden af eller ved at overse denne.

... fejlen må jo opvejes i forhold til hvad man får ved siden af eller ved at overse denne.

Nævn bare én fordel ved at skudsekundfejlen ikke for længst er rettet.

De færreste computere incl. UNIX tæller tid i hele sekunder, så det eneste, man behøver, er at dividere f.eks. en millisekund clock med f.eks. 2 i 2 sekunder. Det kan gøres i interruptroutinen. Så undgår man problemet med 23:59:60.

det er jeg ikke klog nok til, men jeg kunne forestille mig at dem der er, ikke har muligheden. og dem der har muligheden ikke ønsker at bruge resurser derpå.

År 2000 problemet skyldtes udelukkende dårlige programmører, som ikke kunne indse, at hvis man beregnede sig frem til en dato mange år før programmet var skrevet og computeren i det hele taget var opfundet, kunne det måske være hensigtsmæssigt at lægge 100 til årstallet.

År 2000 problemet havde intet med dårlige programmører at gøre, men med dyr memory. Dygtige programmører brugte dagevis på at spare plads i memory fordi der var så lidt af den. Den 1. maskine en stor offentlig transportvirksomhed fik havde 4 KB memory. Det var helt normalt at bruge en uge på at spare 1 byte. Derudover var der ingen der i 60'erne og 70'erne der havde forestillet sig at de systemer de sad og lavede skulle vise sig så levedygtige. Man var sikker på at de ville være blevet erstattet af noget andet længe inden år 2000 problematikken blev aktuel.

Thomas

De færreste computere incl. UNIX tæller tid i hele sekunder, så det eneste, man behøver, er at dividere f.eks. en millisekund clock med f.eks. 2 i 2 sekunder. Det kan gøres i interruptroutinen. Så undgår man problemet med 23:59:60.

Carsten:

Ethvert problem har en letforståelig løsning der overhovedet ikke virker.

Du har lige leveret en sådan.

Hvad sker der med en radar der laver hastighedsmåling hvis der pludselig er sekunder der kører i halv hastighed ?

Ups...

"gummisekunder" duer ikke, punktum!

År 2000 problemet havde intet med dårlige programmører at gøre, men med dyr memory.

Nej, det havde intet med memorystørrelse at gøre! Man brugte ganske rigtig kun to cifre til årstallet og satte så 19 foran - uden at tænke sig om. Èn eneste If statement havde klaret problemet:

Årstal = 1900 + ToCifretÅrstal
If Årstal < ÅrForProgramSkrivning Then Årstal = Årstal + 100

Hvor svært kan det være? Men hellere male fanden på væggen og sende alle amerikanerne ud og købe brændekomfurer end tænke sig bare en lille smule om :-)

Har altid været problemmatisk... jeg har ingen ide hvorfor, men jeg syntes at det er ret ofte et eller andet der går galt.

someDate.addDay( 1 ) - der er ikke mange programmøre der egentligt tænker over hvad der sker inde i. Lægges der en dag til? Er det 24 time? Tages der højde for sommertid? Skudsekundet rammer nok lidt mere marginalt, men er helt enig. Dengang man opfandt den moderne tidsregning havde man ikke tænkt på IT.
Det miljø jeg arbejder med, leveret af big blue, har i sin default installation intet mindre en 4 abstractioner af datoer. Alene det vidner i min verden om at de gyldne sten endnu ikke er fundet.

Men omvendt opgaven er jo netop at gøre det nemt for de andre.

Hvad sker der med en radar der laver hastighedsmåling hvis der pludselig er sekunder der kører i halv hastighed ?

Der sker ikke en dyt, for en radar benytter ikke et ur, men en intern clock med en opløsning på få ns.

Det er klart, at man skal finde en løsning, der passer til opgaven. Den løsning, som jeg foreslog, passer til et computersystem. Har du hørt om nogen radarer, der fejlede pga. skudsekundet?

Har du hørt om nogen radarer, der fejlede pga. skudsekundet?

Ja.

Og det er nok grænsen for hvad jeg må sige om den sag.

Der er desværre nogen der har brug for dem.

Grunden til at astronomer godt kan lide dem, er at 1 sekund forkert tid
fører til at dit teleskop peger 15 buesekunder forkert på himlen.
Der er rigtig meget med moderne teleskoper, specielt hvis man laver interferometri.

Så løsningen må være at vi skiller tidsmåling ad.

En til astronomer. En til os andre.

Hvem der skal have hvad vil jeg ikke blande mig i, da det er en dåse med orm jeg holder mig fra.

Så vidt jeg husker bruger Android gps tid, som allerede er 15 sekunder forkert i forhold til UTC. Dem der bruger det klarer det jo fint nok.

Maagaard

Vi bliver nød til at se på at tid har en stor betydning for vores elektronisk verden.

At kraftværker og vindmøller må stå i tomgang en gang om året, er
vel prisen vi må betale.

Selv tror jeg på at en synkronisering af alt elektronik, ville give et
mere stabilt net og elektronik, og dermed kan vi undgå en del sw fejl.

På hw niveau har man en tidskrystal, som bruges af OS til tidsberegning og sådan en krystal er følsom overfor temperaturændringer, og derfor tror jeg problemet ligger i den.

Derfor mener jeg en lukketid/synkronisering er den løsning jeg kan komme på.

Den med hospitalet havde jeg nu regnet med ville blive nævnt, men
som sagt i andre indlæg, køre de på nødstrøm.

[quote]År 2000 problemet havde intet med dårlige programmører at gøre, men med dyr memory.

Nej, det havde intet med memorystørrelse at gøre! Man brugte ganske rigtig kun to cifre til årstallet og satte så 19 foran - uden at tænke sig om. Èn eneste If statement havde klaret problemet:

Årstal = 1900 + ToCifretÅrstal
If Årstal < ÅrForProgramSkrivning Then Årstal = Årstal + 100

Hvor svært kan det være? Men hellere male fanden på væggen og sende alle amerikanerne ud og købe brændekomfurer end tænke sig bare en lille smule om :-)
[/quote]

Den løsning er ikke generel. Den gælder kun for 2000-2099.

Hvad med at tænke dig bare en lille smule om :-)

[quote][quote]År 2000 problemet havde intet med dårlige programmører at gøre, men med dyr memory.

Nej, det havde intet med memorystørrelse at gøre! Man brugte ganske rigtig kun to cifre til årstallet og satte så 19 foran - uden at tænke sig om. Èn eneste If statement havde klaret problemet:

Årstal = 1900 + ToCifretÅrstal
If Årstal < ÅrForProgramSkrivning Then Årstal = Årstal + 100

Hvor svært kan det være? Men hellere male fanden på væggen og sende alle amerikanerne ud og købe brændekomfurer end tænke sig bare en lille smule om :-)
[/quote]

Den løsning er ikke generel. Den gælder kun for 2000-2099.

Hvad med at tænke dig bare en lille smule om :-)
[/quote]

Vi kan jo altid diskutere, hvem af os, der har tænkt sig bedst om; men min løsning gælder altid 100 år frem i tiden fra det tidspunkt, hvor programmet er skrevet - [b]ikke fra et århundredeskift.[/b] For programmer skrevet i år 2000-2099 skal man naturligvis bruge 2000 i stedet for 1900, men kan stadig nøjes med 2 cifre.

Vi kan jo altid diskutere, hvem af os, der har tænkt sig bedst om; men min løsning gælder altid 100 år frem i tiden fra det tidspunkt, hvor programmet er skrevet - [b]ikke fra et århundredeskift.[/b] For programmer skrevet i år 2000-2099 skal man naturligvis bruge 2000 i stedet for 1900, men kan stadig nøjes med 2 cifre.

Og hvad så hvis man af en eller anden grund i et program fra 1979 har brug for at beregne noget med udgangspunkt i 1978? Da 1978 er < 1979, vil du jo få 2078

Og hvad så hvis man af en eller anden grund i et program fra 1979 har brug for at beregne noget med udgangspunkt i 1978? Da 1978 er < 1979, vil du jo få 2078

Det er klart, at man ikke kan bruge 2 cifre til en kronologisk registrering af klodens historie; men det var vist heller ikke problemet i år 2000. Filosofien er den, at ingen kalender kører baglæns, så starttidspunktet kan af gode grunde aldrig blive før det tidspunkt, hvor programmet er skrevet.

Jeg ved godt, at UNIX/POSIX tæller antallet af millisekunder siden 1. januar 1970 og også kommer i problemer 19. januar 2038, når de 31 bit slipper op; men der er også en skør måde at registrere tid på efter min mening.

Jeg ved godt, at UNIX/POSIX tæller antallet af millisekunder siden 1. januar 1970 [...]

Nej, det gør UNIX/POSIX ikke.

[quote] Jeg ved godt, at UNIX/POSIX tæller antallet af millisekunder siden 1. januar 1970 [...]

Nej, det gør UNIX/POSIX ikke.[/quote]

Muligt; men så må du lige korrigere, hvad der står i denne artikel http://en.wikipedia.org/wiki/Unix_time

UTC tæller millisekunder, men UNIX/POSIX muligvis kun hele sekunder.

Har du hørt om nogen radarer, der fejlede pga. skudsekundet? Ja. Og det er nok grænsen for hvad jeg må sige om den sag.

Smukt svar

UTC tæller millisekunder, [...]

Nej, det gør UTC ikke.

År 2000 problemet havde intet med dårlige programmører at gøre, men med dyr memory.

Sludder. Problemet var, at Microsoft ikke læste årtusindbitten. Det ur, som er placeret i hardware i alle PC'er, har en bit, der er 1 for 19xx, og 0 for 20xx. Den "glemte" microsoft at teste. Det er ikke korrekt, at man havde sparet på bittene. Ur-chip'en, i alle computere der har hardware-ur, er forsynet med de bits, der skal til for at tælle over 100 år. De bruger 8 bit, til at gemme årstallet, og ikke "kun" 5 bits, som microsoft har søgt at bilde verden ind.

Der sker ikke en dyt, for en radar benytter ikke et ur, men en intern clock med en opløsning på få ns.

I et distribueret embedded system er der ofte flere ’clocks’ med forskellige egenskaber som der er ønsker om at kunne ’anvende sammen’.

Mange regulerings systemer er følsomme over for jitter, derfor er det mere og mere normalt at binde systemerne samme hårdt på tværs af noder.
Man kan anvende PTP på tværs af noder i et kontrolnetværk til at synkronisere en distribueret monotonic time som har en accuracy på omkring 20-100 ns.
Denne distribuerede monotonic time vil så have en drift på middel driften af xtal’erne i systemet. (ca. 50ppm over -30° til 60°C for Bilka krystaller )

Denne monotonic time kan så anvendes til styre en PLL til at manipolere prescaleren til timer interruptet i scheduleren. Det betyder at alle noder kan bringes i fase, således at der er en konstant tidsforskel mellem to periodiske tasks der afvikles på to noder.

Denne monotonic time er fint til at tidsstemple således at kronologien af events kan bestemmes på tværs af noder.

Men hvis man får den (halv dårlige) ide at systemet f.eks. skal logge wall clock synkroniserede 10 min middel værdier af noget hvor der indgår tid, så kan der hurtigt komme mærkelige data ud af det.

En løsning kan være at (soft) synkronisere monotonic time samt scheduleren med NTP således at der altid er 1000 styk 1ms timer ticks inden for et UTC sekund.
Resultatet er at scheduleren ikke længere er temperatur afhængig, og der er et konstant antal ticks inden for f.eks. 1 sekund.
Men her skal der selvfølgelig sikres imod at fejl i NTP data ikke kan vælte systemet.

Jeg vil tro at jeg har oplevet 50 forskellige typer HW/SW problemer inden for håndtering af tid.

Jeg vil tro at jeg har oplevet 50 forskellige typer HW/SW problemer inden for håndtering af tid.

Hvis du laver software, der skal fungere over hele verden, og kommunikere sammen på tværs af landegrænser, så er der masser af problemer. Sommertid og vintertid, nogle steder flere sommertider og vintertider i samme land, og halve timer forskudt osv.

I den mindre skala, hvor vi heldigvis ikke behøver synkronisering over landegrænser, kan nævnes f.eks. FPGA'er. De bruger et system, der meget svarer til det du beskriver, for at klokken kan holdes, fra den ene ende af chippen til den modsatte, og for at få den til at passe med ekstern klok.

@ Niels Danielsen

Enheden for tiden er defineret som Ét sekund, og hvis computere har problemer hermed og Skudsekundet, da bliver det værst for samme Computere. På samme måde som når Iran vil anvende computerstyrede ting til Separere Uran, dette kunne om ikke gøres på stenalderniveau så dog på Radiorørsniveau.

Så vidt jeg husker bruger Android gps tid, som allerede er 15 sekunder forkert i forhold til UTC. Dem der bruger det klarer det jo fint nok.

Jeg gik glip af en 1.plads fordi jeg kom 15 sek for sent (eller er det for tidligt?) i mål i forhold til idealtiden, der var efter DFC77 -tid.

Jeg vil tro at jeg har oplevet 50 forskellige typer HW/SW problemer inden for håndtering af tid.

Kender du til noget litteratur, der beskriver (nogle af) de typer problemer du har oplevet? I princippet kan de vel alle undgås, hvis man tænker sig god om, men nogle af os risikerer jo nok alligevel at gentage dem.

År 2000 problemet skyldtes udelukkende dårlige programmører, som ikke kunne indse, at hvis man beregnede sig frem til en dato mange år før programmet var skrevet og computeren i det hele taget var opfundet, kunne det måske være hensigtsmæssigt at lægge 100 til årstallet.

Hvis vi nu skal skille snot fra skidt, så var Y2K "problemet" fuldstændigt forudsigeligt, og mest et produkt af magelighed og kortsynethed. Linux bug'en var en regression indført ved en fejl. Stor forskel.

Muligvis også relateret til dette emne

"The Station and crew were in no danger at any point during the issue – with is under investigation, but may be related to a “leap second” programming implementation into the system over the weekend."

http://www.nasaspaceflight.com/2012/07/iss...

Mvh
Morten

@ Leif Neland

Her står det mig uklart hvem der tager sig selv mest alvorligt, den part der ser skud sekund ordningen afskaffet, eller den part der helst ser ordningen bibeholdt?

Når der argumenteres frem og tilbage, hvem skal da "Helst Vinde og med oplevelsen Vi Vandt!). :-)

@ Leif Neland

I en anden tråd og i en kommentar stod noget jeg tog meget personligt. Har glemt hvor og hvornår. Men som sagt oplevelsen af have fået ret, og i dette konkrete tilfælde ret på den måde at man ligesom har sagt, lad os forsøge udelade de her skudsekunder de kommende 2 eller 3 gange. Og her tænkte jeg inkludere den 30 juni, hvilket ikke skete.

Jeg har først nu læst PHK's glimrende artikel om emnet skudsekunder her: http://cacm.acm.org/magazines/2011/5/10769...

Hvorfor jeg ikke har gjort det før kan jeg ikke forsvare, men til alle som vil have en god introduktion til emnet fra en autoritet, kan jeg varmt anbefale artiklen.

Glimrende artikel PHK! Tak.

@ Lars Bjerregaard

Prøv at opfriske historien om Neptun, hvis bane blev beregnet af en englænder og en franskmænd, men samme planet blev først observeret fra Berlin.
Så måske her ligger en forklaring på bibeholde skud-sekundet :-) altså BIPM i Paris, Longitude og England med mere.

@ Lars Bjerregaard

Først vedtage at enheden for tiden er sekundet, for herefter skulle overtale nogen til lægge et ekstra sekund til hver 18. måned, og vel at mærke gøre dette til et problem.
Piloter der overhører en TCAS Alarm får selv tage konsekvenserne; 250 meter/sekund så sker det noget.

Nogen skriver at Vi korrigerer 1 dag per 400 år i vores kalender. Dette er også en sag med modifikationer. Vi korrigere i årene delelige med 100. :-)

Min påstand er at Philips engang lavede en Video der ikke ville acceptere den 29. febr 2000 "Fordi denne korrigerede i år delelig med 100, hvilket år 2.000 var :-)".

Engang i 50'erne afslog USA blankt en Kalenderreform foreslået fra UN side. Så mon ikke der er kommet et Njet, denne gang fra amerikansk side. Om bibeholde det her skud-væsen. (U-væsen).

Hvis jeg brændte for afskaffe denne ordning, være som slå i en dyne.

@ Eskild Nielsen

Hvad man IKKE må sige om en ting.

OK, er det den slags argumenter man vil bruge for bibeholde Skud sekundet. For da vil jeg skrive hvad er det man IKKE må sige om Planeten MARS ?

Så kunne man nedsætte en Komite til ændre på Cs tidsstandarden således der gik 6 eller 10 år imellem der var et skudsekund. Reglen om at det er Jorden som taber i fart, i modsætning til stabiliteten i Cs systemet. Reglen om arbitrært fastsætte hvad man nu ønsker at fastsætte.
Meterstandarden i Paris forbliver nok den samme, inklusive afstanden til månen (Laser med mere).

Meterstandarden i Paris forbliver nok den samme, [...]

Nej, for meteren er defineret i forhold til sekundet nu om dage :-)

Yes men prøv så omdefinere samme sekund i forhold til meteren; dette vil vel skabe endnu mere furore :-)

OK modstanderne af samme skud sekund mener altså at en korrektion omkring 1/46 000 000 af et sekund (1 og et 1/2 år), er endnu mere No go end bibeholde de her leap-seconds.

Altså omdefiner Cs standarden!

Når personer der har med tid at gøre, taler om hvad som sker efter 500 år, hvis man afskaffer skudsekunderne.

Kan sådanne mennesker overhovedet tages alvorligt? Tager de sig selv så alvorligt? Derfor mit spørgsmål om man om 40.000 år må korrigere i aarene delelige med 80, i stedet for som nu delelige med 100? Om jeg tager mig selv alvorligt, næppe.

De parter der mener De har problemer med skud sekunderne, burde samme ikke tage sig nogle forholdsregler der "omgår problemet". Ligesom reglen om de der har behov for en, mere nøjagtig tid, også bør "Gøre en egen indsats herfor".

Umiddelbart synes jeg det ligner at de mest udbredte workarounds falder i to kategorier, dvs. enten 1) "Time smear" (Carsten Kanstrups idé ovenfor, blot gjort en smule mere "enklave"-venlig):

http://googleblog.blogspot.dk/2011/09/time...

Eller, a.la. 2) nøjes med blot tælle tiden i sekunder i stedet for at tænke i minutter eller andre "besværlige" menneske- eller astronomienheder:

http://en.wikipedia.org/wiki/Precision_Tim...

Ang. 2) kan man vel argumentere lidt frem og tilbage, hvorvidt der egentligt er tale om et workaround eller en reel løsning.

Men hvad har folk mon ellers valgt at gøre i det virkelige liv - gerne med succes (og dermed ikke sagt at "med tordnende fiasko" ikke ville være mindst lige så interessant :-))?