NTP server řešící přechod na letní čas

[Pivson]

Hoj, pouzivam chronyd a potreboval bych resit, jak tupym klientum servirovat 'koncovej' cas (tj. aplikovat posun a zimni/letni). chronyd (a ntpd, ...) ale neumi moc rozlisovat mezi 'systemovym' a tim co posila z server z pohledu jineho NTP klienta. Umi jen posun bez aplikace zimniho/letniho nesmyslu (chrony). Tupy klient ma v tomto omezene moznosti a jedina rozumne automatizovatelna cesta je dat mu cas 'is-is'.

Cili - neznate nekdo rozumneho ntp servera, ktery by vzal systemovej cas (UTC, synchronizuje se samostatne) a udelal z nej zdroj, ktery bude posunut na nasi aktualne platnou zonu ? S tim, ze nechci nekde editovat (= zapomenout) konfig, kdy se prepina, tj. musi to sosat ze systemovych local dat (cas je ale UTC), nebo si to brat online (da se to vlastne nekde automatizovane najit ?). Server sam o sobe musi byt UTC. Mit systime v localtime je naprd, udela to bordel vsude jinde...

Diky, ja nic nenasel.

P.

[Reklama]

[bmn]

Je to hrozná prasárna, ale pokud to fakt jinak nejde, tak dávat lokální čas místo UTC by měl chronyd zvládnout.
Důležitá je -x volba, co vypne synchronizaci systémových hodin. Pak s volbou offset se dá čas libovolně posunout. Synchronizovat se může třeba s lokálním serverem běžícím na jiném portu nebo rozhraní. Nějak takhle:

chronyd -x "pidfile /run/chrony2.pid" "allow" "server 127.0.0.1 port 12123 offset $((3600 * $(date +'%:::z')))"

Restartovat se to může každý den ráno nebo bez restartu by to šlo pomocí chronyc nebo přes soubor v sourcedir.

[Pivson]

Diky! To je docela "pěkný" - nenapadlo mně "nedělat sync" defacto.

Nejde, protože ty zařízeni jsou demetní a všechny by musel někdo při změně času "oklikat" (ssh to nemá, jen web plnej šílených skriptů, takže automatizovat by bylo peklo a při změne FW znova...). Typicky ruzne kamery a spol.

P.

[Filip Jirsák]

Nebylo by lepší mít ta koncová zařízení v UTC? Obávám se, že takovýmto šachováním docílíte akorát toho, že se na čas v zařízení nebude dát vůbec spolehnout – a to nejen tu jednu hodinu na podzim, kdy se lokální čas „opakuje“. Některé implementace (např. referenční ntpd) se chovají tak, že pokud je rozdíl lokálních hodin a času přijatého přes NTP příliš velký, usoudí, že je něco špatně a synchronizaci úplně zastaví.

[Pivson]

UTC - za mně rozhodně souhlas. Ale vysvětluj lidem, že čas na kameře/... je jinej. A ještě ke všemu 2x za rok se přepočet změní Přistupují k tomu už BFU (k obrazu) a zkušenost velí, že by někdo dokola řešil stížnosti na špatný čas A množina těch lidí je velká, prostor může/musí vidět/sledovat kdokoliv dle potřeb defacto. Kdyby šlo jen o pár lidí (ala ochranka)....

Nicméně to je přesně jádro pudla. Co je menší zlo. Řešit s někým dokola co je to UTC (překvapivě mnoho lidí to nezná... zvláštní) nebo to, že v záznamu může hodina být přeskočena, nebo pro změnu zmizet (3->2 a minulá hodina se přepíše a chvilku kamera vidí budoucnost . Případně když se to drbání levou nohou za pravým uchem (chronyd vs. chronyc vs. systime) nepovede...

P.

[Reklama]

[Filip Jirsák]

Musí ten čas do obrazu vypalovat kamera, nebylo by lepší řešit to až někde dál ve fázi zpracování/uložení?

Chápu, že řešíte, co je menší zlo. Mne hlavně fascinuje, že někdo vyrobí kameru, která do obrazu vypaluje čas, která se umí synchronizovat s NTP (které je z definice v UTC) a neumí pracovat s časovým pásmem. To musel navrhnout někdo, kdo spadl z Marsu. Pochopil bych, že se na to někdo vykašle a vypálí do firmware databázi časových zón, takže bude problém při změně. Ale že s časovými zónami někdo nepočítá vůbec, to fakt nechápu.

[nameLoginUserWhatever]

UTC - za mně rozhodně souhlas. Ale vysvětluj lidem, že čas na kameře/... je jinej. A ještě ke všemu 2x za rok se přepočet změní Přistupují k tomu už BFU (k obrazu) a zkušenost velí, že by někdo dokola řešil stížnosti na špatný čas A množina těch lidí je velká, prostor může/musí vidět/sledovat kdokoliv dle potřeb defacto. Kdyby šlo jen o pár lidí (ala ochranka)....

Aka je to znacka kamery nech viem co nekupovat, ked budem potrebovat dalsiu IP kameru . Lebo Dahua kamery to maju dobre spravene, vo webovom rozhrani sa da nastavit kedy sa ma prejst na DST a kedy ho vypnut.
http://dahuawiki.com/images/1/1a/DST_Example_WestCoast.png

[nameLoginUserWhatever]

Musí ten čas do obrazu vypalovat kamera, nebylo by lepší řešit to až někde dál ve fázi zpracování/uložení?

IP kamera posiela stream zakodovany H.264/H.265, ak by som tam chcel vlozit na serveri cas do toho videa, tak ho musim dekodovat, vlozit cas a znova enkodovat do H.264/H.265, co je jednoduhsie, mat kameru, ktora vlozi cas do videa (a nema problem s letnym casom) alebo mat zbytocne vykonny server, ktory musi dekodovat a enkodovat niekolko streamov realtime.

[_Tomáš_]

můžeš sdělit typ kamery? Jsi si jistý, že není jiná možnost? Samotný NTP protokol má poměrně dost obran právě proti tomu, aby šířil výrazně posunutý čas, takže to je vyloženě běh proti zdi.

Typ s chrony od bmn je asi nejlepší řešení, restart přesně o půlnoci je řešitelná věc. Vše ostatní bude až příliš komplikované.

[Tomáš G.]

Trošku blbá situace, ale správný postup je reklamace. Kdysi jsem si koupil věž a po rozbalení v ní chrčel ventilátor. Byl to celkem velký eshop a známá tam pracovala, takže byla schopna podchytit stav, kdy já to vrátím bez udání důvodů a oni si to nějak vyřeší s výrobcem/servisem. Dál už to šlo mimo mě.

[hahel16625]

Mne hlavně fascinuje, že někdo vyrobí kameru, která do obrazu vypaluje čas, která se umí synchronizovat s NTP (které je z definice v UTC) a neumí pracovat s časovým pásmem. To musel navrhnout někdo, kdo spadl z Marsu. Pochopil bych, že se na to někdo vykašle a vypálí do firmware databázi časových zón, takže bude problém při změně. Ale že s časovými zónami někdo nepočítá vůbec, to fakt nechápu.

Ne z Marsu, z Číny. Prostě udělají kameru, která zná jeden čas a netuší nic o časových pásmech. A pak někdo přijde s tím, že zákazníci chtějí synchronizaci s NTP. Tak to tam dobastlí. Že to dohromady nedává smysl, to nikoho nezajímá. Prostě ta kamera to umí, v popisu produktu si mohou zaškrtnout políčko s NTP a hotovo.

[Filip Jirsák]

Prostě udělají kameru, která zná jeden čas a netuší nic o časových pásmech.

Už tohle samotné vede na to, že tam musí dvakrát ročně někdo vlézt do administrace a čas přenastavit. NTP na tom už nic nezhorší.

Ocenil bych, kdyby se mezi možné důvody reklamace výrobku dostalo i to, že sice výrobek formálně odpovídá popisu, ale nikdo nemohl očekávat, že se bude chovat až takhle blbě.

[hahel16625]

Prostě udělají kameru, která zná jeden čas a netuší nic o časových pásmech.

Už tohle samotné vede na to, že tam musí dvakrát ročně někdo vlézt do administrace a čas přenastavit. NTP na tom už nic nezhorší.

1) Výrobce prodává, výrobce nic nenastavuje. Nastavuje uživatel (oddělení provozu), které občas může kecat do toho, co mu v oddělení investic koupí, občas do toho kecat nemůže.
2) V Číně se na letní čas nehraje, takže kamera, která pracuje pouze s jedním (pásmovým) časem, tam nemá v principu konkurenční nevýhodu ani ve firmách, kde má provoz právo kecat do toho, co se koupí.
3) Mnoho zařízení běží s jedním časem (tím, který platil, když se to instalovalo). A všichni ví, že ten čas je půl roku správný a půl roku o hodinu posunutý. A jsou na to zvyklí a jsou s tím smíření.

[Filip Jirsák]

2) V Číně se na letní čas nehraje, takže kamera, která pracuje pouze s jedním (pásmovým) časem, tam nemá v principu konkurenční nevýhodu ani ve firmách, kde má provoz právo kecat do toho, co se koupí.

V Číně se dříve letní čas používal. A nemyslím si, že by třeba webová administrace té kamery byla jen v čínštině – oni to dobře vědí, že to prodávají do celého světa. Spíš platí to, že dostáváme takovou kvalitu, jakou si zaplatíme.

Mně na tom nevadí, že to v Číně v téhle kvalitě vyrábějí. Vadí mi, že prakticky nejde tuhle nekvalitu odmítnout – protože že je to šmejd zjistíte, teprve když to dorazí, a pak už je neekonomické pokoušet se to nějak vracet, takže nezbývá než to tady nějak dobastlit. Ale klasická kapitalistická poučka „poučíte se a příště u nich nekoupíte“ tu nefunguje, protože až budete kamery kupovat příště, nekoupíte to od téhle firmy prostě proto, že už nebude existovat – a koupíte to od jiné, která vyrábí naprosto stejné šmejdy (možná i na té stejné lince a se stejnými lidmi).

[hahel16625]

2) V Číně se na letní čas nehraje, takže kamera, která pracuje pouze s jedním (pásmovým) časem, tam nemá v principu konkurenční nevýhodu ani ve firmách, kde má provoz právo kecat do toho, co se koupí.

V Číně se dříve letní čas používal. A nemyslím si, že by třeba webová administrace té kamery byla jen v čínštině – oni to dobře vědí, že to prodávají do celého světa. Spíš platí to, že dostáváme takovou kvalitu, jakou si zaplatíme.

Mně na tom nevadí, že to v Číně v téhle kvalitě vyrábějí. Vadí mi, že prakticky nejde tuhle nekvalitu odmítnout – protože že je to šmejd zjistíte, teprve když to dorazí, a pak už je neekonomické pokoušet se to nějak vracet, takže nezbývá než to tady nějak dobastlit. Ale klasická kapitalistická poučka „poučíte se a příště u nich nekoupíte“ tu nefunguje, protože až budete kamery kupovat příště, nekoupíte to od téhle firmy prostě proto, že už nebude existovat – a koupíte to od jiné, která vyrábí naprosto stejné šmejdy (možná i na té stejné lince a se stejnými lidmi).

Letní čas se v Číně použil naposledy v roce 1991. To jsou ve vývoji elektroniky tak řekněme 3 generace vývojářů.
Oni vyrobí něco, co je dost dobré pro obří místní trh a jak vidno, tak se to dobře prodává i globálně (ty důvody 1+3). Do kolika jazyků přeloží webové rozhraní, celkem není zajímavé.

Já osobně velmi silně sdílím vaši frustraci z toho, jsem byl u dalšího výrobku opět oblafnut, že to sice má funkci X, ale ta funguje tak, že to není použitelné pro typické použití, kde se nasazují výrobky s funkcí X. Ale spíš jde o to, že existuje dost lidí, kterým to takto vyhovuje, pro které je to dobré dost.
Když koupíte výrobek od evropského výrobce, tak ho vrátíte velmi snadno. I od evropského distributora to jde pořád snadno. Ale chtěli jsme totéž výrazně levněji přímo z Číny a teď vidíme, že totéž není "totéž".