Přechod zimní->letní čas – MySQL – Fórum – Programujte.com

Ahoj,

při nedávné změně na letní čas mne napadla otázka, co se stane na podzim při změně na zimní čas? Mám tabulku, kde sloupec typu datetime je současně primárním klíčem. Měřená veličina je změřena 1x za sekundu a spolu s datem a časem vkládána do databáze. Klíčová situace nastane ve 2:59:59. Za jiných okolností by následoval čas 3:00:00, při změně na zimní čas ale následuje 2:00:00. Když vložím záznam obsahující 2:00:00 letního času, jak bude vyhodnocen pokus vložit záznam obsahující 2:00:00 zimního času?

hu

#1 hlucheucho
Pokud budeš datum a čas vždy ukládat se správnou časovou zónou, tak k problému nedojde - interně se vždy ukládá v UTC, které letní čas nepoužívá. Při prezentaci se pak opět zobrazí správný čas se správnou zónou.

Ještě je v tom jeden problém. Čas měření vkládá zařízení, které měření provedlo. Při přenosu dat na server může dojít ke zpoždění. Asi by měřící zařízení muselo generovat čas v UTC.

hu

#3 hlucheucho
UTC na zařízení by bylo ideální.

Také je možné generovat časové razítko až na serveru (v databázi). S tím bývá nejméně problémů.

Měření je real time. Čas generovaný databází by v sobě zahrnoval (nepředvídatelné a někdy i velké) zpoždění způsobené přenosem po síti, pro tento případ je nepoužitelný. Čas generovaný real time měřícím zařízením a přenášený spolu s naměřenou hodnotou je přesnější.

hu

Pak bys nejspis musel cas prevadet na UTC, pokud UTC negeneruje zarizeni. Na zaklade predpokladu, ze zpozdeni by nebylo delsi nez hodinu.

Tam je chyba už při návrhu databáze - primární klíč má být vhodného datového typu, unikátní, a zejména zcela samostatný, bez vlastního významu.

#7 RomanZ
Za normálních okolností datum a čas je unikátní hodnotou, jediné místo, kde je trochu problém je hodinový úsek při přechodu letní - zimní čas. Mít jako primární klíč nějakou int hodnotu která je v tabulce jen do počtu je k ničemu. Nejjednodušší je použít zimní čas trvale, pak se tato jediná drobná nevýhoda tohoto primárního klíče vytratí. Tato vlastnost sloupce pak zjednodušuje kontrolu dat a další práci s nimi.

hu

RomanZ - Jj, ale myslim si, ze problem je jinde. Ze ma zarizeni, ktere mu posila data v nejakem formatu, do ktereho nemuze sahat. A muze se stat, ze mu posila treba balicek nekolik dat v jinacim poradi nebo dorazi cast dat opozdene. To zarizeni id negeneruje, jen casove razitko a to jeste v ne moc vhodnem formatu. To ma pak tezky :)

#8 hlucheucho
V tom se neshodneme. Primární klíč má být hodnota bez vlastního významu. Kdo tohle pravidlo ignoruje, zadělává si na problémy. Už třeba - co kdyby těch zařízení měl víc a dvě zapsala ve stejný čas? Co dělají ta zařízení v chybovém stavu, nepošlou náhodou čas ve tvaru 00:00? I to s tím letním/zimním časem by se vyřešilo, kdyby měl primární klíč integer-autoincrement - viděl by změnu času a zároveň by nepřišel o informaci, který záznam přišel dřív a který později.

Zkrátka "Mít jako primární klíč nějakou int hodnotu která je v tabulce jen do počtu" je právě o tom, že není jen do počtu, odděluje to skutečná data od identifikace záznamu v databázi.

V případě, že zařízení pošle nevalidní data, je vhodnější zaznamenat chybu namísto dat. Důležité je chronologické řazení záznamů. Dvě zařízení nemohou zapisovat do jedné tabulky. Uspořádání tabulky by mělo být podřízeno účelu, maximálně zjednodušit vkládání a výběr dat.

Docela se mi líbí řešení, které má ČHÚ třeba u radarových dat. Čas je v UTC, bez zimního/letního času. Tento přístup pak vede k tomu, že neexistují dvě hodnoty naměřené ve stejný den a čas. Pak je tedy datum a čas unikátní a lze tuto vlastnost použít pro kontrolu, zda se v tom někdo nevrtal nebo zda nedošlo k poruše. Nejjednodušeji se to provede tak, že v db je tento sloupec unikátní a pokus o vložení nevalidních dat vede k zaznamenání chyby. Existence více unikátních sloupců v jedné tabulce sice není problém, ale v tomto konkrétním případě by existence sloupce s unikátní int hodnotou nebyla přínosem.

Ještě jeden důvod, proč použít UTC , je srozumitelnost pro uživatele. Představ si vykreslený graf teploty v čase. V UTC mám na vodorovné ose čas kontinuálně plynoucí do budoucnosti. Při přepnutí letní/zimní čas mám v průběhu jedné hodiny dvě hodnoty ve stejný čas - docela matoucí. Podobné je to u přechodu zimní/letní čas - v datech je hodina díra.

Naproti tomu auto increment int jako primární klíč v jiných případech používám - pokud je to přínosem nebo pokud není jiná možnost (ne vždy je v datech něco unikátního).

hu