23:59:59 23:59:60 00:00:00

Noc z 30. června na 1. července byla o tzv. přestupnou sekundu delší. Některé systémy a služby měly s touto změnou vážné problémy. Článek na Wired.com zmiňuje například problémy s Java/Cassandra nebo Java/Hadoop. Také některé linuxové systémy měly problémy.

2.7.2012 14:26 | Ladislav Hagara | Zajímavý článek

Komentáře

[Šangala]

Tento stav 23:59:59 23:59:60 nemá nikdy nastat, spávně je:
23:59:58 23:59:59 23:59:59 00:00:00
nebo se pletu?

A i kdyby, čemu to prakticky vadí, co se zblázní (v Linuxu, ne v Javě už byly aj horší divnosti)?

[Ondrej 'SanTiago' Zajicek]

Myslim ze pletes, AFAIK spravne podle prislusnych standardu je 23:59:60, ale UNIXove programy se asi obecne budou chovat spis tak jak jsi popsal, protoze od jadra zjisti cast pres gettimeofday() (ci obdobne alternativy), ktery vraci UNIX time, a nasledne si ho zkonvertuji do human-readable reprezentace. A UNIX time neumozni rozlisit 23:59:59 a 23:59:60 (mapovani neni jednoznacne, obema casum odpovida stejny UNIX time, tedy behem prestupne sekundy je UNIX time neplynuly).

Nevim, zda je to tento pripad, ale muze se zblaznit treba kod, ktery je v jadre specielne pro osetreni prestupne sekundy (osetreni skoku v unix time).

[Šangala]

Tak beru zpět, nevím kde jsem k tomu došel (ale byl jsem o tom, a už dlouho, skálopevně přesvědčený), ale fčul sjem si přečetl i RFC3339 a na internet opravdu ta 60-ka patří, ale stejně nevím čemu to vadí…

[Bedňa]

Pretože ľudia keď píšu kód na kontrolu správnosti času, tak sekundy sú [0..59] a ak tam je iné číslo vyhodí chybu.

[Šangala]

To chápu - nedělal bych to jinak :)

[Heron]

No a potom ten kód má za něco stát, když se sere na RFC případně rovnou na standardy.

[j]

To musel byt pekny blb, kterej to tam dal ... to je ostatne pricina zhrouceni se ruznych aplikaci. kdyby to jednoduse 2s ukazovalo 59, tak to aplikace nepoznaj a je jim to putna.

[Filip Jirsák]

Aplikace občas pracují i s jemnějším dělením, než jedna sekunda. Takže je potřeba jim poskytnout správný čas, a obezličky typu dvousekundové sekundy použít jenom pro aplikace, které s tím nepočítají.

[j]

To nic nemeni na tom, ze prinos tyhle kraviny je 0, zato problemu s tim spojenych je oo.

[Filip Jirsák]

To, že vy přínos nevidíte, ještě neznamená, že neexistuje. Vážných problémů s tím spojených je jeden, a to chyba v linuxovém jádře. Ta už je snad opravená. Pak jsou drobné chyby v různých programech, jejichž autoři programují jen tak od oka, takže se jim občas přihodí nějaké neštěstí – tu má únor nečekaně 29 dní, tu má minuta nečekaně 61 sekund… Tak je holt potřeba ty programy upravit, lidi už si zvykli, že v poledne je Slunce nad hlavou a Vánoce jsou v zimě, a nehodlají to kvůli pár programátorům neumětelům měnit.

[Ondrej 'SanTiago' Zajicek]

No, trend oddelovat casove jednotky od prirozenych astronomickych cyklu je vcelku jasne videt - napojeni mesicu na lunarni cykly zcela zmizelo jiz davno (kdyz civilizace prechazely na solarni kalendare), dnes si to zachovavaji co vim akorat Arabove. Pevne spojeni kalendarniho roku s astronomickym solarnim rokem jiz take vpodstate zmizelo a misto toho bylo nahrazeni pravidelnym cyklem o prumerne delce presne 365.2425 dne. Tam si pevne spojeni pro zmenu uchovava napr. iransky kalendar. Takze je otazka, zda podobne odpojeni si nezaslouzi i den.

Co se tyce toho pozadavku na synchronizaci, tam si je dobre uvedomit, ze lidem (pokud nejde o specializovane astronomicke aplikace) je uplne jedno, kdyz je ta odchylka rozumne velka. Napr. hrubost casovych zon vytvari odchylku mistniho casu od presneho solarniho az 30 min na hranici casovych pasem (nehlede na DST, ktere tu odchylku zvetsi o dalsi hodinu). Zruseni prestupnych sekund by vedlo k driftu AFAIK cca 20 min za 500 let ci cca hodinu za tisic let. To by asi lide v klidu tolerovali.

[K]

Napr. hrubost casovych zon vytvari odchylku mistniho casu od presneho solarniho az 30 min na hranici casovych pasem (nehlede na DST, ktere tu odchylku zvetsi o dalsi hodinu).

Kdyby jen hodina.

Čína má jen jeden čas.

China Standard Time (UTC+8)

[nyan]

Kdyby jen hodina.

Čína má jen jeden čas.

China Standard Time (UTC+8)

Epic. Takze pri obedu na jednom konci ciny koukaj na zapad slunce, na druhem na vychod slunce ?

[Jendа]

Ve Španělsku se občas shiftnou skoro o 3 hodiny, takže mají Slunce v zenitu kolem 14:40.

Úžasné jsou taky zóny posunuté o necelé násobky hodiny - Indie +5:30, Nepál +5:45.

[imploder]

Shiftnou se jenom o 1 hodinu. V zimě mají Slunce v zenitu kolem 13:40. Je to kvůli tomu, že mají středoevropský čas (CET), i když jsou od střední Evropy daleko na západ (dokonce na západ od 0°). S posunem na letní čas to nesouvisí. Tady v ČR to máme dobrý, u nás na 15°E je s CET poledne přesně ve 12:00, v létě ve 13:00.

[Jendа]

Timeshift zde byl ve smyslu rozdílu mezi místním časem a časem oficiální zóny.

[Filip Jirsák]

Máte pravdu. Ale všechno jsou to malé odchylky kolem nějakého středu, který se snažíme udržet správně. Řešit to jednou za čas skokovým posunem se v minulosti zkoušelo, a byly s tím problémy. Proto se zavedlo průběžné korigování – ať už v podobě gregoriánského kalendáře, nebo později v podobě přestupných sekund. A když ty přestupné roky zvládli už v 16. století, mohli bychom to v 21. století s celým tím IT zvládnout taky, ne?

[Ondrej 'SanTiago' Zajicek]

To ale nezminujes podstatny rozdil mezi prestupnymi roky a prestupnymi sekundami. Prestupne roky gregorianskeho kalendare neni zadne prubezne korigovani - to je systematicke pravidlo s pevnou prumernou delkou roku, ktera je sice blizsi astronomickemu cyklu nez predchozi juliansky kalendar, ale stejne casem udriftuje pryc (protoze tam zadna prubezna astronomicka korekce neni). Prubeznou astronomickou korekci ma jiz zmineny iransky kalendar, kdy se novy rok vyhlasuje vzdy podle astronomicke jarni rovnodennosti.

Ony skoro vsechny problemy (a bugy) nejsou spojene s prestupnou sekundou jako takovou, ale s tim, ze se umele vklada v nepravidelnych intervalech (v zavislosti na astronomickych pozorovanich).

BTW, prestupne roky mel i predchozu juliansky kalendar, ale vzdy jednou za 4 roky, bez upravy pro 100 a 400-nasobky.

[Filip Jirsák]

Ony skoro vsechny problemy (a bugy) nejsou spojene s prestupnou sekundou jako takovou, ale s tim, ze se umele vklada v nepravidelnych intervalech (v zavislosti na astronomickych pozorovanich).

Opravdu? Který například? Zrovna ten současný v jádře byl způsoben přestupnou sekundou jako takovou, nikoli jejím nepravidelným vkládáním.

BTW, prestupne roky mel i predchozu juliansky kalendar, ale vzdy jednou za 4 roky, bez upravy pro 100 a 400-nasobky.

A právě ta úprava pro 100 a 400-násobky dělá taky spoustě programů problémy a byla to součást problému roku 2000. Přesto se zdálo rozumnější opravit chybné programy, ne chybným programům přizpůsobovat celý svět.

[Ondrej 'SanTiago' Zajicek]

Opravdu? Který například? Zrovna ten současný v jádře byl způsoben přestupnou sekundou jako takovou, nikoli jejím nepravidelným vkládáním.

Treba ten soucasny. Kdyby prestupna sekunda byla pravidelna, tak by byla implementovana ciste v userspace (v prepoctu z unix time na 'viceslozkovy' (broken-down) time), tykala by se pouze interakce s uzivatelem a interni unix time by bezel plynule.

Protoze je ale prestupna sekunda nepravidelna, dava vetsi smysl mit interni unix time ingorujici prestupne sekundy, prepocet na viceslozkovy cas uniformni ignorujici prestupne sekundy, a prestupnou sekundu resit sekundovym skokem v internim unix time. No a v dusledku toho skoku se projevily ty bugy.

Nelze proste srovnavat problemy s prestupnou sekundou s problemy se spatne implementovanym prestupnym rokem. Zatimco to druhe jsou trivialne odstranitelne chyby, to prvni jsou fundamentalni problemy, ktery ma kazda casomira ci kalendar zalozeny na astronomickych korekcich namisto na pravidelnych cyklech.

[Martin Mareš]

Protoze je ale prestupna sekunda nepravidelna, dava vetsi smysl mit interni unix time ingorujici prestupne sekundy, prepocet na viceslozkovy cas uniformni ignorujici prestupne sekundy, a prestupnou sekundu resit sekundovym skokem v internim unix time. No a v dusledku toho skoku se projevily ty bugy.

Mimochodem, takhle to pod UNIXy vždycky nebylo. Staré UNIXy měly interní čas podle TAI a přestupné sekundy se ošetřovaly až při konverzích v userspacu. Po pravdě řečeno, přišlo mi to tak praktičtější.

[Ondrej 'SanTiago' Zajicek]

Vazne? To me prekvapuje, pokud vim, tak jak POSIX tak NTP vicemene predokladaji, ze to bude podle UTC.

Mit systemovy cas v TAI je urcite konceptualne elegantnejsi, ale kdyz si zase predstavim problemy se synchronizaci seznamu prestupnych sekund a problemy, ktere by to prineslo napr. embedded systemum s jedinym zapisovatelnym mistem v RTC, ci offline systemum, tak bych hadal, ze by to v praxi fungovalo hure.

[Martin Mareš]

Vazne? To me prekvapuje, pokud vim, tak jak POSIX tak NTP vicemene predokladaji, ze to bude podle UTC.

Však mluvím o UNIXech daleko starších než POSIX a asi i než NTP :)

Mit systemovy cas v TAI je urcite konceptualne elegantnejsi, ale kdyz si zase predstavim problemy se synchronizaci seznamu prestupnych sekund a problemy, ktere by to prineslo napr. embedded systemum s jedinym zapisovatelnym mistem v RTC, ci offline systemum, tak bych hadal, ze by to v praxi fungovalo hure.

Offline systémy se tak jako tak nemohou s přestupnými sekundami vypořádat. A jakmile systém používá nějakou formu synchronizace času z externího zdroje, obvykle přitom získává i informace o přestupných sekundách a je jeho věc, jestli si podle nich upraví systémový čas, nebo přepočítávací tabulky mezi systémovým a kalendářním časem. I embedded systémy obvykle mají nějakou nevolatilní paměť, do které si informace o přestupných sekundách mohou uložit.

[pavlix]

V podstatě by udržování informace o počtu zatím nabraných vteřinách (jeden integer) bylo víceméně ekvivalentní současné situaci. Lepší schéma se schopností počítat na vteřinu delší časové úseky už potřebuje ukládat seznam.

[Ondrej 'SanTiago' Zajicek]

Abys byl schopen korektne dekodovat starsi timestampy, tak by ti nestacilo znat pouze pocet, ale musel bys znat i to, kdy byla ktera ktera prestupna sekunda. Oproti tomu soucasny system umoznuje korektne dekodovat starsi timestampy bez ohledu na tohle.

To je trochu problem i s navrhovanou synchronizaci tohoto seznamu u offline systemu - i kdyz se cas synchronizuje treba pres DCF77 nebo GPS, tak ta informace je tam jenom implicne a pokud by system byl delsi dobu vypnut, tak uz by si tu tabulku korektne nesestavil (u DCF77 by zrejme stacilo mit system vypnuty cca hodinu pred a behem prestupne sekundy). A to ani nemluvim o offline systemu s casem synchronizovym uzivatelem. Ale je pravda, ze dnes je stejne prakticky vse pripojene do Internetu, takze to je dost nevyznamny problem.

[pavlix]

Abys byl schopen korektne dekodovat starsi timestampy, tak by ti nestacilo znat pouze pocet, ale musel bys znat i to, kdy byla ktera ktera prestupna sekunda. Oproti tomu soucasny system umoznuje korektne dekodovat starsi timestampy bez ohledu na tohle.

Ondro to sis mohl dát práci s přečtením poslední věty... ale vlastně je o srovnání všech tří možností celý můj komentář.

Zbytek je jasný, offline přístup k čemukoli proměnlivému je problém.

[Ondrej 'SanTiago' Zajicek]

No, myslim, ze ta prvni veta (ktere jsem hlavne oponoval) byla trochu zavadejici - ten rozdil je vyraznejsi na to, aby slo to shrnout jako 'vicemene ekvivalentni'.

Co se tyce schopnosti, tak by to slo asi usporadat takto:

1) system s TAI a citacem - ten akorat umi zobrazit aktualni cas a dekodovat timestampy z blizke minulosti

2) soucasny system - umi dekodovat vsechny timestampy, ale uz neumi spocitat delku casoveho intervalu zdaneho dvema daty.

3) system s TAI a databazi leap seconds - ten umi i pocitat ty intervaly.

A protoze dekodovani starsich timestampu je mnohem dulezitejsi funkce nez pocitani delek intervalu (prvni je potreba kazdou chvili a je soucasti standardniho unixoveho rozhrani, to druhe je spis hricka), tak spis jako 'vicemene ekvivalentni' je mozne oznacit 2) a 3).

[pavlix]

No, myslim, ze ta prvni veta (ktere jsem hlavne oponoval) byla trochu zavadejici - ten rozdil je vyraznejsi na to, aby slo to shrnout jako 'vicemene ekvivalentni'.

Vznikala by tam nepřesnost v řádu přestupných sekund, která by ale šla při znalosti seznamu přestupných sekund odstranit. Pro praktické účely mi to přijde velice podobné. Jen se zbavím skoků za cenu určitých malých nepřesností (dokud nedoplním informaci o historii přestupných sekund).

Ale to už je věc názoru, ne faktů, takže nevidím důvod o tom polemizovat. Alespoň s tvého současného příspěvku je jasné, co máš namysli.

A protoze dekodovani starsich timestampu je mnohem dulezitejsi funkce nez pocitani delek intervalu (prvni je potreba kazdou chvili a je soucasti standardniho unixoveho rozhrani, to druhe je spis hricka), tak spis jako 'vicemene ekvivalentni' je mozne oznacit 2) a 3).

Tady je chyba v předpokladu, že zachování délek intervalů pomáhá pouze jejich výpočtu pro informativní účely, což je značně zpochybněno právě tou chybou, o které je zprávička.

[Jendа]

Oproti tomu soucasny system umoznuje korektne dekodovat starsi timestampy bez ohledu na tohle.

Ale nedokážeš korektně (jednoznačně) zapsat/dekódovat timestampy kolem půlnoci dne s LS, ne?

[Ondrej 'SanTiago' Zajicek]

To je pravda (jak uz jsem tu parkrat zminil).

[pavlix]

To je další věc, ten vztah není bijektivní. Podle mě je to průser a špatný způsob vypořádání se s problémem.

Normální linuxový systém měl IMO mít základní časomíru shodnou se skutečným plynutím času a tabulku korekcí. Sice by to u rok neaktualizovaného systému mohlo znamenat třeba vteřinovou odchylku při zobrazování času, ale to bych neviděl až tak kritické a dalo by se to řešit i na jiné úrovni než u systémových aktualizací.

Časové zóny se taky mění kdykoli si někdo vzpomene.

[Käyttäjä 11133]

Tak kdyby se pro distribuci tabulky korekcí používalo NTP, tak by to vlastně nebyla změna oproti současnosti. Systémy bez NTP se zpravidla rozbíhají o minuty tak jako tak, a všechny NTP enabled systémy by neměly problém.

Dokonce si myslím že by nebylo potřeba předělávat samotný NTP protokol, jen by se udělalo něco jako diff system-time ntp-time > time-map-table

[pavlix]

Jo, jenže pro přepočítávání potřebuješ právě znát celou historii přestupních vteřin.

[Jendа]

Opravdu? Který například?

Třeba ten designový, že nevíme, za jak dlouho bude za rok.

[Filip Jirsák]

Koho něco takového zajímá?

[Jendа]

Třeba se hodí spočítat, kdy mám vyměnit palivo v reaktoru.

[Filip Jirsák]

Ovšem to se počítá s tolerancí týdnů nebo měsíců, to přestupná sekunda nerozhází. A pokud to potřebuju s tolerancí na sekundu, uložím ten údaj jako 78 892 314,9 sekundy od okamžiku poslední výměny.

[Jendа]

Ještě před chvílí byla minutová tolerance Slunce v nadhlavníku něco, proti čemu je třeba bojovat, a pak zase byl letní čas super věc. Nějak tomu nerozumím…

[Lol Phirae]

To neřeš, normální jirsákovina.

[pavlix]

Napr. hrubost casovych zon vytvari odchylku mistniho casu od presneho solarniho az 30 min na hranici casovych pasem (nehlede na DST, ktere tu odchylku zvetsi o dalsi hodinu).

A to se ještě bavíme o geografických časových pásmech, ne o politických, viz třeba španělsko.

Zruseni prestupnych sekund by vedlo k driftu AFAIK cca 20 min za 500 let ci cca hodinu za tisic let. To by asi lide v klidu tolerovali.

Mohlo by se to čas od času korigovat posunutím nultého poledníku :).

[nyan]

Zruseni prestupnych sekund by vedlo k driftu AFAIK cca 20 min za 500 let ci cca hodinu za tisic let. To by asi lide v klidu tolerovali.

Nikoli. Jak bylo psano jinde... nejen ze je prestupna sekunda nepravidelni, zpomalovani rotace zeme je nelinearni - za par stovek let muze byt prestupni vterina kazdy mesic.

[pavlix]

Nikoli. Jak bylo psano jinde... nejen ze je prestupna sekunda nepravidelni, zpomalovani rotace zeme je nelinearni - za par stovek let muze byt prestupni vterina kazdy mesic.

„Nikoli“ znamená, že nemá pravdu. Jenže následující věta nepravdivost jeho tvrzení vůbec neimplikuje.

[Ondrej 'SanTiago' Zajicek]

Podle [1] je to zpomalovani v dlouhodobem prumeru linearni (a tedy akumulovana odchylka kvadraticka) a to s tempem prodlouzeni stredni delky dne o 1.7 ms za stoleti, z toho jsem vychazel. Je tam jeste nejaka dlouhodobe fluktuace s periodou cca 1500 let a amplitudou cca 4 ms/stoleti, ale ta ted naopak zacina zpomalovani snizovat, takze v neblizsich nekolika stoletich by to melo byt spis mene (odhadem 5 min za 500 let a 30 min za tisic let).

[1] F. R. Stephenson and L. V. Morrison: Long-Term Fluctuations in the Earth's Rotation: 700 BC to AD 1990

[pc2005]

odchylku mistniho casu od presneho solarniho

Přesný solární čas? Vždyť má dobu trvání 3600*24 s přesahem +-30 sekund během roku. Rozhodně bych podle slunce nic důležitého neřídil.

Vlastně ono je docela vtipné, že vůbec chce někdo něco v počítačích řídit podle periody, která ani neznamená jednu otočku Země okolo své osy (viz ten obrázek).

[Filip Jirsák]

Vlastně ono je docela vtipné, že vůbec chce někdo něco v počítačích řídit podle periody, která ani neznamená jednu otočku Země okolo své osy

To je právě to zásadní nepochopení. Datum a čas tu nejsou kvůli počítačům. Byly tady už dávno před nimi a měly za úkol pro lidi označit oběh Země okolo Slunce a rotaci Země. Když počítače mají údaje o čase prezentovat lidem, mají používat míru, kterou jsou lidé zvyklí používat. Takže se holt počítače budou muset nějak vypořádat s přestupnými roky, přestupnými sekundami a změnami časových pásem. Výkonu na to mají dost.

[pc2005]

Datum a čas tu nejsou kvůli počítačům.

Ano jsou tu pro lidi a proto by měly být v počítačích použity jen a pouze pro rozhraní sloužícímu komunikaci s lidmi. Rozhodně by neměly způsobovat deadlocky. Nebo chceš snad vyvinout procesor s časovačem v šedesátkové soustavě s přestupnými sekundami?

[Šangala]

Počítače možná mají, ale ty lidi co s tím dělají na to nemají nervy, a to jak ti dole co „tvoří“ a neví jak to uchopit, tak ti nahoře, kteří se dozví termín „přestupná sekunda“ a přestávají věřit svým hodinkám . Hovoříme-li o „zvyku“ tipl bych si, že ten „obecný zvyk“ bude bez povědomí o přestupných sekundách.
Byť čas 2012-06-30 23:59:60 je platný, tak ho nezná skoro žádný „engine“, (MySQL, M$SQL a další) a ať hledám jak hledám (přeháním, zas tak aktivní nejsem), tak jsem zatím nenašel nic co by fungovalo takto:

2012-07-01 00:00:00 - 2012-06-30 23:59:59 = 2

Zkoušel jsem i 1997-07-01 00:00:00 - 1997-06-30 23:59:59 = 2

[petr_p]

Ano, málo jste hledal:

$ cat time
#!/usr/bin/perl

use strict;
use warnings;
use DateTime;

my $before = DateTime->new(
    year      => 2012,
    month     => 6,
    day       => 30,
    hour      => 23,
    minute    => 59,
    second    => 59,
    time_zone => 'UTC'
);
my $after = DateTime->new(
    year      => 2012,
    month     => 7,
    day       => 1,
    hour      => 0,
    minute    => 0,
    second    => 0,
    time_zone => 'UTC'
);

print "$after - $before = ", ($after - $before)->seconds, "\n";

$ ./time 
2012-07-01T00:00:00 - 2012-06-30T23:59:59 = 2

[Šangala]

…ale účel to splnilo, ne(?) :)…, ale:

2012-07-01T00:00:00 - 2012-06-30T23:59:59 = 1
1997-07-01T00:00:00 - 1997-06-30T23:59:59 = 2
aptitude update
aptitude dist-upgrade
2012-07-01T00:00:00 - 2012-06-30T23:59:59 = 1
1997-07-01T00:00:00 - 1997-06-30T23:59:59 = 2

(ani u 2012 to nesežere hodnotu 60 pro sec.)
Asi logické, i když bych už čekal změnu na druhých dvou řádcích, ale jinak „sfiňa by se z teho zblula“ - jak se pak máme domluvit.
<joke>Mám další důvod proč nepoužívat Perl, bo se nedomluví s okolím.</joke>

[petr_p]

Máš používat normální distribuci :) DateTime changelog:

0.71   2012-01-05

- There will be a new leap second on June 30, 2012.

[Šangala]

Aspergerův syndrom mi nedovoluje moc rychlé změny

[J]

Mno chyba ... me teda pocitat s vterinama 0-59 neprijde jako chyba, me prijde jako naprosto zasadni chyba resit ptakoviny jako vterinovou ochylku od astronomickyho casu. To necht si resi badatele. Kvuli podobnym hovadinam pouzivam na vsech serverech UTC (abych nemusel resit letni cas) a voiala, yntelygenty vyrobej prestupnou vterinu ...

Sem zvedav co bude chudak kernel delat, az si vzpomenu, ze je vlastne vsechno spatne, a ze unor bude mit semo tamo dnu 30. Chci videt, s jakou odchylkou pracuje 99,999% linuxovych stroju. Moc pod vterinu to nebude - staci kdyz se podivam do logu ntpcka. Tudiz se tu kvuli ptakovine, ktera nikoho (a do prakticky naprosto doslova) nezajima, placa energii nejen fyzickou, ale i dusevni tisicu lidi, kteri to musi resit.

BTW: Prislo mi upozorneni od dodavatele zalohovani, ze si to mam pres vikend radsi vypnout ... lol.

[Filip Jirsák]

Tyhle „ptákoviny“ se řeší už pár set let. Neschopnost pár programátorů asi nebude ten pravý důvod, proč to přestat dělat. Vždyť naopak počítače umožňují s tím pracovat mnohem snáz…

[Ondrej 'SanTiago' Zajicek]

Ne, prestupna sekunda je tu cca 40-50 let, od doby, kdy sekunda prestala byt definovana jako zlomek stredni delky dne, a zacla byt definovana pres kmity atomu cesia.

[Filip Jirsák]

Což je pořád kapánek déle, než linux a celé IT. Takže přizpůsobit se asi bude muset ten, kdo přišel později a je v menšině. Jinak já jsem myslel hlavně přestupný rok, což je úplně ten samý princip – únor má normálně 28 dní, ale někdy 29, minuta má běžně 60 sekund, ale někdy jich má 61. A ví se s dostatečným předstihem, kdy ten výjimečný případ nastane.

[Ondrej 'SanTiago' Zajicek]

No, podle Wikipedie se prestupna sekunda objevila v 1972, zatimco prvni varianty unix time uz v 1971.

Kdo je v mensine je otazka - tusim ze orientacni pruzkum mezi zastupci ITU ohledne zruseni prestupne sekundy byl vyrazne ve prospech zruseni a o zruseni prestupnych sekund se jiz nejakou dobu jedna.

[Jendа]

A ví se s dostatečným předstihem, kdy ten výjimečný případ nastane.

Asi máme každý jiné vnímání dostatečného předstihu. Zatímco zjistit, kolik dní bude mít únor roku 2132, je triviální, kolik sekund bude mít poslední minuta tohoto roku nikdo neví.

[Filip Jirsák]

Kdo to potřebuje vědět? Fakt mne napadají jenom samé varianty, kdy někdo místo časového okamžiku ukládá interval nebo opačně.

[Smazáno]

Kvuli podobnym hovadinam pouzivam na vsech serverech UTC (abych nemusel resit letni cas) a voiala, yntelygenty vyrobej prestupnou vterinu ...

Tys mě rozesmál. Víš co je UTC ty yntelygente? A proč je přestupná sekunda integrální součástí právě toho UTC, co používáš na svých 'serverech'? Voilà ty vteřino...

[Filip Jirsák]

voiala, yntelygenty vyrobej prestupnou vterinu

Jinak přestupná sekunda byla vymyšlena a poprvé zavedena v roce 1972. To je jen taková poznámka pro ty, co mají pocit, jaká je to strašná novinka, a že by se to mělo jejich pécéčku přizpůsobit.

[Jendа]

Aha, proto mají v Brně Slunce nad hlavou ve 13:08. A dokonce i na 15. poledníku je UTC vzhledem k astronomickému času plus mínus autobus.

Mně zase přijde divné, že nemůžu říct, kolik hodin bude za půl roku.

[Suchý čert]

Podle ISO 8601 nastane 23:59:60, v unixovém čase se jedna sekunda opakuje dvakrát, což znamená, že pokud měříte s větší přesností než na sekundy, tak v pozdějším čase dostanete nižší hodnotu než v dřívějším, s čímž programy často nepočítají. Pokud program měří časové intervaly, je proto vhodnější místo reálného času používat CLOCK_MONOTONIC (std::chrono::steady_clock), který tento problém nemá.

[Jardík]

Ostatně programy, které používají systémový čas pro výpočty typu "jak dlouho to trvá" či pro "počkej 3 sekundy", jsou bastl. Nejen že se pose*ou při přestupné sekundě, oni se pose*ou vždy, když změníte systémový čas.

[nyan]

A i kdyby, čemu to prakticky vadí, co se zblázní

no dle toho TFA, na linuxu se zblazni kernel, proste bug v kodu

Krom toho existuje nezname (pravdepodobne dost velke) mnozstvi softwaru v ruznych zarizenich, ktereho programatori pocitali s tim ze 23:44:55 + 3600 = 00:44:55

BTW s tou prestupni sekundou jeste bude zabava. Nastava zcela nepravidelne; zatim nikdo neprisel na system v te nepravidelnosti (tj neumi ji predvidat); a navic se rotace zeme zpomaluje ne linearne, ale spis exponencialne, IIRC za nekolik malo stovek let by mela byt leap second kazdy mesic

[Kvakor]

Onehdy jsem si říkal, že nejlepší by bylo u interní reprezentace času vykašlat se na rotaci Země a používat například GPS čas, který přestupné sekundy nejsou. Aktuálně je tam rozdíl 18 sekund, což je důvod, proč některé GPS příjímače vracejí o tento interval posunutý čas, dokud si nestáhnou almanach (a to trvá až 12 minut).

Bohužel ani toto rešení není ideální, protože v almanachu je pro přestupné sekundy vyhrazeno jen 8 bitíků, takže pokud se bude rotace zpomalovat stejným tempem, tak v roce 2300 nejspíš přetečou.

Mimo toho, musely by se upravit části operačních systémů a/nebo knihoven (např. v Linuxu by stačili ty knihovny), co mají na starost převod mezi časy v lidském formátu a timestampem. Navíc by musel existovat nějaký konfigurační soubor, který by říkal, kolik sekund kdy bylo přidáno, což by byl problém u offline systémů. To už je asi jednodušší opravit ty programy, které to rozhodí ...

[Dreit]

Myslim že v roce 2300 už dnešních GPS satelitů moc fungovat nebude

[pc2005]

Ale třeba takovej Hubble by to mohl dát .

[Jendа]

Krom toho existuje nezname (pravdepodobne dost velke) mnozstvi softwaru v ruznych zarizenich, ktereho programatori pocitali s tim ze 23:44:55 + 3600 = 00:44:55

Tam by měl být spíš smutník. Mně přijde tragické, že nevíme, za jak dlouho bude „za rok“.

[pc2005]

Je právě tolik kolik je, datum není důležité, místo taky ne. (tak schválně kdo bez googlení pozná)

A teď si vem, že pokud poletíš relativistickou rychlostí (vlastně stačí i letadlem okolo země, pokud trváš na hodně malém zlomku sekundy), tak v tom budeš mít ještě větší guláš.

[Jendа]

Proč? Rychlost znám, tak prohlásím, že reference je na Zemi a basta.

[pc2005]

No a stejně tak můžeš říct, že za půl roku bude přesně za tolik a tolik tiků cesiových hodin.

[Ondrej 'SanTiago' Zajicek]

Nemuzes, protoze za pul roku (brano kalendarne jako datum navysene o 6 mesicu) muze byt za X nebo X+1 tiku cesiovych hodin, podle toho, zda mezi tim nastane prestupna sekunda.

[pc2005]

Ad patička: Hmm úplnej prequel k filmu Kontakt .

P.S. Škoda jen, že výpočetní kapacita mozku je omezená .

[nyan]

Mně přijde tragické, že nevíme, za jak dlouho bude „za rok“.

Noo... obe vyrazy "v stejnou dobu o rok" a "o 365 dni" maji svuj smysl, a je spis otazka aplikace kdy kterej pouzit. Problem je spis ze spousta programatoru si neuvedomuje ten rozdil, a pouzijou prvni co je napadne.

[pavlix]

„Ve stejnou dobu o rok“ či „ve stejný den za rok“ tak, jak to intuitivně chápu, není přesně definované a i kdybych si zvolil definici, která se mi líbí, tak to rozhodně není bijekce. Jako programátor bych bez dalšího upřesnění zvolil +365 s tím, že přesný výsledek neumím a nepřesnost se mi zdá přijatelná :). Na ošetření silvestra přestupného roku bych se tiše vykašlal, dokud by si někdo nestěžoval....

Takhle se to přece dělá, ne?

[Jendа]

Doufejme, že nějaká kritická real-time aplikace nepředává jadernému plánovači informace tímto způsobem…

[J]

Souhlas, navic kdyz uz, tak se podobne udalosti definuji jinak - "sejdeme se pri pristim slunovratu" = bez diskusi presne urceni casu, jen se nevi, kolik casu mezi tim uplyne ... coz vychazi z toho, ze se definice casu odchylila od prirodnich cyklu.

A chci videt aplikaci, ktera pocita, kdy presne ten pristi slunovrat nastane, aby vratila dotycnemu spravny "cas".

[Jendа]

Ano, ale mě zajímá, kdy mám vytáhnout ten vzorek z reaktoru…

[pc2005]

Si kup hodinky počítající TAI . Pak už není problém udělat aplikaci, co bude čítat do nuly (asi myslíš biologický reaktor, u jaderného by pak měl ten countdown ještě druhou vlastnost ).

[Jendа]

• Nevím, za jak dlouho bude St čec 3 14:58:14 CEST 2012.
• Nevím, kolik hodin bude za 3600*24*365 sekund.
• "o 365 dni" a "o 3600*24*365 sekund" jsou rozdílné údaje. A nebo taky ne. Podle toho, kdy zrovna vyjde Slunce.

[Martin Mareš]

Prostě je potřeba uvědomit si, že intuitivní požadavky, které klademe na kalendář a časomíru, jsou navzájem ve sporu, takže řešení, které by splnilo všechny, nemůže existovat.

Pro čas požadujeme, aby byl měřitelný čistě mechanicky.

Od kalendáře chceme, aby odpovídal přírodě kolem nás. Například aby jaro začínalo v březnu.

Jenže pokud se Země bude nadále točit nepravidelně, jak činí, nezbude, než se jednoho z požadavků vzdát nebo zavádět komplikovanosti typu přestupných sekund, či případně se vzdát dlouhodobé udržitelnosti kalendáře a říci si, že je lepší nechat odchylky akumulovat a pak jednorázově udělat velký skok.

[pc2005]

+1 !

[Dreit]

Nebo zavoláme do Ruska! Když poroučí větru, dešti, proč by nemohli říct Zemi aby se přestala zpomalovat?

[Ondrej 'SanTiago' Zajicek]

Obligatory xkcd reference.

[Ondrej 'SanTiago' Zajicek]

Nerekl bych, ze to je uplne presne.

U toho casu je hlavne pozadavek na presnost casomiry a 'konstantnost' sekundy, kdyz je brana jako zakladni fyzikalni jednotka. To vedlo k definici SI jednotky sekundy nezavisle od dennich cyklu.

Kdybychom napr. pro bezne ucely (s vyjimkou specializovanych aplikaci ci vedeckych mereni) merili cas v 'paleosekundach' (definovanych klasicky jako 1/86400 dne) namisto v SI sekundach, tak by to byl cas meritelny ciste mechanicky (prevazna vetsina beznych meridel ma stejne presnost takovou, ze rozdil mezi SI sekundou a 'paleosekundou' asi nehraje roli) a pritom by nebyl potiz s navaznosti na kalendar. Ale melo by to zas jine potize (napr. nutnost udrzovat dve infrastruktury, jednu pro 'civilni' cas, druhou pro 'vedecky' cas).

Naproti tomu i kdyz si odmyslime casomiru a budeme brat ciste kalendar, tak tam jsou obdobne potize mezi dennim, mesicnim a rocnim cyklem a, jak zminuju tady, vyvoj jde smerem k mechanizaci a odpoutani od prirodnich cyklu. Dnes zachovavame uz pouze denni cyklus, mesicni jsme zrusili uplne a rocni mechanicky aproximujeme a tedy casem oddriftuje.

[Martin Mareš]

[...] pritom by nebyl potiz s navaznosti na kalendar.

Ta svá každodenní nepřesná měřidla ovšem čas od času seřizujeme podle nějakých přesnějších: podle časových signálů v rádiu apod. A tahle přesnější měřidla by už problémy s návazností měla.

Ale souhlasím, že by mohlo být lepší přesnou synchronizaci kalendáře s přírodou vzdát a místo toho udělat jednou za pár set let velký skok.

[David Watzke]

Na pár serverech se zbláznila Java a začala žrát 100 % CPU.

[nyan]

Na pár serverech se zbláznila Java a začala žrát 100 % CPU.

Ja myslel ze to je jeji normalni stav ( tj zrani 100% CPU )

(Apologies for trolling )

[AsciiWolf]

+1

[David Watzke]

To nic, my jsme si tu z toho taky dělali srandu. No, na těch serverech to normální stav není, ale chápu, že vypořádat se s extra sekundou může být pro někoho náročné

[Dreit]

Normálně žere 100% CPU a dělá že něco dělá, teď žrala 100% a nedělala projistotu vůbec nic

[Filip Jirsák]

Ve skutečnosti se to nezbláznila Java, ale linuxové jádro.

[Jardík]

Tam vidím datum "15 Mar 2012" což je pár měsíců zpět. Pokud vývojáři distribuce neaktualizují a nechávají bugy (např. debian stable "bugyjsounámukradený"), tak jim to patří.

[Ondrej 'SanTiago' Zajicek]

Jeste prihodim odkaz k zpravicce o (hadam) minule prestupni sekunde: Způsobila přestupná sekunda pády systémů?

Jinak se jedna o zruseni prestupnych sekund z bezneho civilni casomiry: viz, naposledy to tusim odlozili.

[Radovan Garabík]

Nihil sub Linuce novum...

[pc2005]

Jo kdyby vývojáři používali hodnotu nějakýho systémovýho counteru (kdysi PIT), tak by se to nestalo .

[qwertz]

hm.. zajimave

#!/bin/php
<?

echo mktime(23,59,58,6,30,2012)."\n";
echo mktime(23,59,59,6,30,2012)."\n";
echo mktime(23,59,60,6,30,2012)."\n";
echo mktime(0,0,0,7,1,2012)."\n";

?>

./xtest.php 
1341093598
1341093599
1341093600
1341093600

Ja myslim ze timestamp by mel pokracovat nerusene dal bezohledu na prestupne sekundy atd., a menit by se mela az interpretace timestampu, tedy prepocet na dny, minuty, hodiny, sekundy, mesice, roky, atd. U prestupneho roku kdy ma unor 29 dnu take nevracime timestamp o 86400 sekund zpet. Letni zimni cas se take nevraci zpet timestamp, ale meni se interpretace. Pokud je to pocet sekund od 1.1.1970, pak to znamena ze si myslim ze by spravne melo byt

1341093598 = 30.6.2012 23:59:58
1341093599 = 30.6.2012 23:59:59
1341093600 = 30.6.2012 23:59:60
1341093601 = 1.7.2012 0:0:0

a nebo klidne treba

1341093598 = 30.6.2012 23:59:58
1341093599 = 30.6.2012 23:59:59
1341093600 = 30.6.2012 23:59:59
1341093601 = 1.7.2012 0:0:0

IMHO pokud uz mame prestupnou sekundu, tak dle timestampu, ktery 2x zopakuje tutez vterinu prestupna sekunda vubec nenastala a tudiz odted je timestamp o vterinu mensi nez opravdovy pocet sekund od 1.1.1970 a proto definice ze unix timestamp je pocet sekund od 1.1.1970 odted neni pravdiva. Spravne je pocet sekund od 1.1.1970 a pocinaje 1.7.2012 0:0:0 je to pocet sekund od 1.1.1970 - 1 sekunda, pokud se 1.7.2012 0:0:0 = 1341093600. Pokud se 1.7.2012 0:0:0 = 1341093601 pak zustava pravda ze unixtimestamp je pocet sekund od 1.1.1970.

Ale mozna se mylim.

[Šangala]

To tady už bylo naspáno, že převod na UNIX time (timespamp) takto funguje a je ne-jednoznačný.
PS: Přestupných sekund o od roku 1970 už bylo 25. A UTC se od atomového času nyní liší o 35 sec.

[motyq]

no to jsi nemel ani psat.. kolik je teda vlastne hodin? sakra! A co na to EU? Nejake vseobecne narizeni zakazujici zpomalovani rotace zeme by to chtelo!

[Ondrej 'SanTiago' Zajicek]

Viz man 2 time:

POSIX.1 defines seconds since the Epoch using a formula that approximates the number of seconds between a specified time and the Epoch. ... This value is not the same as the actual number of seconds between the time and the Epoch, because of leap seconds and because system clocks are not required to be synchronized to a standard reference.

Tedy UNIX time definovan jako pocet sekund od epochy ale bez zapocitani prestupnych sekund.

[Ladislav Hagara]

Přestupná sekunda způsobí, že rezervační systém Amadeus nefunguje, odbavování cestujících Quantas a Virgin Australia vázne, letový plán jde do kytek. Více než 400 letů je zpožděno o více než dvě hodiny.

[Ladislav Hagara]

Přestupná sekunda způsobí, že procesory jedou na 100% a tím nároste spotřeba elektřiny v datacentru o megawatt.

[pavlix]

Konečně se o linuxu píše :D. A ta reklama na Red Hat Enterprise Virtualization se nad článek o havarovaných linuxových systémech vyloženě vyjímá :D. To je ostuda, pánové.

[Dreit]

Já bych všechny ty sekundy zakázal

 

Nebylo by pomalu lepší přestupnou sekundu počítat jako další den? Když už to umí 29. února, tak proč nevytvořit 31. června? Sice by ten den existoval jen jednu sekundu, ale to by snad nebyla žádná tragedie

[pc2005]

Nebo nultého července.

[Dreit]

Myslim že to už by software nezvládal tak dobře

[David Watzke]

Software se podělá z jedný sekundy navíc a ty bys mu chtěl předhazovat sekundovej den? Seems legit.

[Dreit]

Taky pravda...

[Dreit]

Zpět.

Myslel jsem to tak, že určitě bude jednodušší jednu sekundu vydávat za den, než vydávat dvě sekundy za jednu. Ostatně do jednoho dne se ta sekunda vejde krásně (a několikrát!), zato zařídit aby 2=1 bude problematičtější, jak jsme se ostatně nedávno přesvědčili.

[Šangala]

To vlastně tento kód, za běžných podmínek (bez násilné změny času):

timeval tv;
double start,end;
gettimeofday(&tv, NULL);
start = tv.tv_sec + ((double)tv.tv_usec)/1000000;

//measured code

gettimeofday(&tv, NULL);
end = tv.tv_sec + ((double)tv.tv_usec)/1000000;
printf("\nMeasured time: %f sec\n\n",(end-start));

může nejen vrátit špatný údaj, ale dokonce teoreticky záporný čas.
Asi předju na:

struct timespec tv;
double start,end;
clock_gettime(CLOCK_MONOTONIC, &tv);
start = tv.tv_sec + ((double)tv.tv_nsec)/1000000000;

//measured code

clock_gettime(CLOCK_MONOTONIC, &tv);
end = tv.tv_sec + ((double)tv.tv_nsec)/1000000000;
printf("\nMeasured time: %f sec\n\n",(end-start));

[jbohac]

Přesně tak.

Měřit jak dlouho něco trvá pomocí CLOCK_REALTIME (a přesňě to dělá i gettimeofday) je blbost. Přestupná vteřina je jen jeden z případů kdy se to rozbije. Úplně stačí aby během měření někdo nastavil čas pomocí date.

Přesně k tomu je CLOCK_MONOTONIC.

[Šangala]

PS: Když někdo nastaví čas pomocí date, tak je to vůl (nepočítaje při instalaci systému) .

[Ondrej 'SanTiago' Zajicek]

A proc? Od doby, co mame CLOCK_MONOTONIC, neni snad moc duvodu aby programy mely potize se skokovymi zmenami casu.

[pavlix]

Bůůůůůůůůůůůů.

Jednu dobu tuším ntpd neumožňoval korekci času při zjištění příliš velkého rozptylu. Platí to ještě? A mimochodem v návodech se ntpdate nacházel hojně a dokonce se tam objevovala i zvěrstva typu volání ntpdate z cronu.

Těch volů po světě bude...

[Ondrej 'SanTiago' Zajicek]

Dela to tak defaultne, opacne chovani (skok pri vetsim odchylce) je option -g. Ja osobne bych preferoval option pro skokovou zmenu vzdy pri startu, nebo aspon pro vyrazne zmenseni hranicni hodnoty te odchylky.

[pavlix]

To by se mi taky notebook nemusel nikdy zesynchronizovat a to osobně považuju za větší problém než když se rozsype nějaká aplikace (tedy konkrétně u notebooku).

[Filip Jirsák]

Platí to stále. Distribuce to většinou řeší tak, že na začátku init skriptu se zavolá ntpdate a teprve pak se nastartuje ntpd. Při řešení problémů s ntpd si něco o volech myslím často, ale vždy je to adresováno autorům tohoto báječného kusu softwaru…

[pavlix]

Distribuce to většinou řeší tak, že na začátku init skriptu se zavolá ntpdate

Distribuce jsou tedy volové :).

Při řešení problémů s ntpd si něco o volech myslím často, ale vždy je to adresováno autorům tohoto báječného kusu softwaru…

Nejsi sám, proto přece máme chronyd :).

[Šangala]

Při startu to obvykle nevadí, protože se nepředpokládá, že tato změna provede posun dozadu…

[pavlix]

Při startu to obvykle nevadí

To si přesně myslím, že to při startu nevadí.

protože se nepředpokládá, že tato změna provede posun dozadu…

Zdroj?

[Šangala]

Pitné vody?

[pavlix]

Vidím, že jsem na poznámu o volech měl reagovat poznámou o husách, zvláště těch potrefených :).

[Šangala]

Jo, můžeme si založit místní zoo, našli by se i další druhy. :)

[pavlix]

Hmm, přitom se mi zdá, že to K celkem funguje...

[Filip Jirsák]

Nejsi sám, proto přece máme chronyd

Jenom aby ten projekt zase neumřel, jako všechny předchozí alternativy k ntpd...

[pavlix]

Já zatím nemám nastudováno v čem je dobrý a v čem je špatný a ani na to v nejbližší době nebudu mít čas. Jestli to umře nebo neumře mě momentálně zas až tak netrápí, protože ntpd používám velmi jednoduše a chronyd mi na první dojem nepřišel až tak skvělý.

Třeba jsem chtěl jednoduše zjistit údaje o používaných serverech a chtěl jsem dát chronyd příkaz k jednorázovému srovnání času. Chyba byla do určité míry na mojí straně, ale to CLI je neintuitivní.

[Šangala]

OK, tak tedy „sebevrah“ .
PS: To není výzva, ale možnost volby, buď je vůl, protože je mu to jedno co to ovlivní, a nebo je sebevrah a nevadí mu rozhození sandálu u spousty aplikací (třeba jen záznamů v DB, které se provádí za sebou a uha podle time nejsou za sebou).
Systémový čas se může zpomalit / zrychlit snad i zastavit, ale vždy musí udržet dopřednou posloupnost tj. nesmí se nikdy vrátit, taková drobnost, může rozhodit sandál spoustě věcí a bránit se tomu by bylo sakramentsky drahé a musel by každý prvek.
Ano, při startu/restartu systému, nejlépe s minimem věcí v běhu, to je ok, ale dozadu jen max o interval, který trval restart.

[pavlix]

Já osobně jsem pro rozumná řešení. Ale v praxi používám to, co je k dispozici.

[Ondrej 'SanTiago' Zajicek]

No, asi se muzeme shodnout, ze pokud nekdo provozuje databazi se zaznamy, ktere musi byt udrzovany setrizene podle nejakeho realneho data, pak by mel systemove datum menit bez skoku dozadu. Pokud ne, tak je to vcelku jedno. Jasne, jeste tady existuji veci zavisle na timestampech souboru (make a asi zalohovani), ktere by to mohlo rozbit, ale jinak bych tipoval, ze prevazna vetsina potizi s tim jsou spis chyby v software nez nezbytne pozadavky na presny realny cas.

[Šangala]

No nevím, viděl jsem i mnohem jednoduší aplikace, které se zbláznili posunem času do zadu…, ale hlavně těžko se definuje, která aplikace se o něco takového opírá a kolik aplikací používá své databáze. Posun dozadu, prostě poruší základní „pevný bod“.

[Ondrej 'SanTiago' Zajicek]

Coz bylo nejspis proto, ze pouzivali time() ci gettimeofday() namisto clock_gettime(CLOCK_MONOTONIC) pro rizeni svych smycek ci relativnich timeru.

Ja znam programy, ktere se zblazni, kdyz se system suspenduje a po delsi dobe probudi (kvuli skoku dopredu se zrejme snazi vykonat spoustu periodickych udalosti), ale to je take chyba tech programu.

[Šangala]

To může mít i daleko jednoduší příčinu, když se posune čas třeba o několik sekund nebo dokonce minut zpět (skokem). Může to být na daleko vyšší úrovní, pouhé porovnání dvou datum-časů, z kterého vyleze záporný čas, nebo třeba se jen z uživatelské historie, nějaké aplikace zjistí, že odpověď došla dřív, než byla poslaná otázka (jsou to věci, které by mohly/měly být assert-ovány).
Zkusím to bez ZOO a s jinou osobou : „Když posunu čas zpět za chodu sytému (včetně Desktopu, o serveru nemluvě), tak si říkám o problémy a můžu si za to sám, protože ‚dopřednost‘ času nemám porušovat.“

[pavlix]

„Když posunu čas zpět za chodu sytému (včetně Desktopu, o serveru nemluvě), tak si říkám o problémy a můžu si za to sám, protože ‚dopřednost‘ času nemám porušovat.“

S tím naprosto souhlasím. Používej jenom pokud víš, co děláš. Nicméně pak je dobré si hodně hlídat správné nastavení času a jeho budoucí synchronizaci. Btw mně minimálně jednou ujel čas ve Fedoře na Lenovu se singlebootem přesně o hodinu a dle všeho to nebyl problém časové zóny. Ale už nejsem schopný to zreprodukovat.

[Filip Jirsák]

Co když je v HW hodinách počítače uložený nějaký nesmyslný čas a po zapnutí počítače se systémový čas nastaví třeba o několik měsíců dopředu? Podle mne i v takovém případě je nejlepší čas při spouštění ntpd nastavit na přesný čas.

Pokud je nějaká aplikace na přesném čase závislá, měla by se spouštět až po úspěšném nastartování služby pro seřizování času. Případně i kontrolovat, zda služba funguje správně, což je zrovna u ntpd problém...

[Šangala]

Pokud dojde k situaci, že čas byl totálně mimo - už je to stejně rozkokošené, takže nejmenší zlo je nastavit správný čas.
Přímočaře jsem se snažil výjadřit, že používání date k nastavení času, se musí opatrně a každý administrátor by si měl dávat bacha, jestli nenastavuje čas dozadu. Kdybych musel nastavit čas dozadu o více než nějaké sekundy za chodu serveru, tak bych ten server raději otočil a nastavení nechal provést co nejdříve po restartu, nebo po shození služeb před restartem.

[pc2005]

Příloha:

• outtime.sh (818 bytů)

Zajímavý, mě nikdy při hraní si se skriptem z přílohy nic v kompu nemrzlo.

[Šangala]

Buď rád :) <joke>, ale abys za 3 měsíce nezjistil, že máš rozhašené účetnictví…</joke>

[pavlix]

Ale to je velice hezký nápad. Samozřejmě s možností to obejít.

[Šangala]

Je to o důsledném dodržování rozdílu mezi „interval“ a „časový údaj“ (bod na časové ose) - teorie pěkná, ale v praxi taky potřebujeme často znát interval umístěný v čase a pak se dostáváme k nepříjemným rozhodnutím, a klademe si otázky „je to opravdu interval nebo jsou to dva body na časové ose?“, „mám provést dvě různé měření (CLOCK_REALTIME i CLOCK_MONOTONIC)?“, „když uchovám dva body a interval, kdy a kdo to první nesprávně použije a polezou z toho ‚jiné‘ výsledky“ a spoustě dalších…

[David Jaša]

Když jsem to četl, napadlo mě přirovnání ke staticky určitému vs. neurčitému nosníku. :) Holt u intervalu mohou být bezproblémově zadány jen dva ze tří parametrů (začátek, délka, konec), ten zbývající se musí dopočítat. Při takovém přístupu mi připadá problematický jen případ, kdy znám délku a konec časového úseku a během jeho trvání přibude přestupná sekunda - nicméně na druhou stranu, pokud to něco rozhodí nepřesnost v řádu setin procent, zaslouží si to zhebnout. :)

[Jardík]

<rejp>Pro vás platil můj komentář.</rejp>

[Šangala]

A dřív jsem měříval i přes clock();.