Přechod zimní->letní čas – MySQL – Fórum – Programujte.com
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

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

 

27. 3. 2017   #1
-
0
-

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

Nahlásit jako SPAM
IP: 195.178.67.–
Kit+14
Guru
27. 3. 2017   #2
-
0
-

#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.

Nahlásit jako SPAM
IP: 85.93.112.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
27. 3. 2017   #3
-
0
-

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

Nahlásit jako SPAM
IP: 195.178.67.–
Kit+14
Guru
27. 3. 2017   #4
-
0
-

#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ů.

Nahlásit jako SPAM
IP: 85.93.112.–
Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
27. 3. 2017   #5
-
0
-

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

Nahlásit jako SPAM
IP: 195.178.67.–
peter
~ Anonymní uživatel
3618 příspěvků
28. 3. 2017   #6
-
0
-

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

Nahlásit jako SPAM
IP: 2001:718:2601:26c:6173:b5...–
RomanZ
~ Anonymní uživatel
269 příspěvků
28. 3. 2017   #7
-
0
-

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.

Nahlásit jako SPAM
IP: 194.212.10.–
28. 3. 2017   #8
-
0
-

#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

Nahlásit jako SPAM
IP: 195.178.67.–
peter
~ Anonymní uživatel
3618 příspěvků
28. 3. 2017   #9
-
0
-

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 :)

Nahlásit jako SPAM
IP: 2001:718:2601:26c:6173:b5...–
RomanZ
~ Anonymní uživatel
269 příspěvků
28. 3. 2017   #10
-
+1
-
Zajímavé

#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.

Nahlásit jako SPAM
IP: 194.212.10.–
28. 3. 2017   #11
-
0
-

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

Nahlásit jako SPAM
IP: 195.178.67.–
Zjistit počet nových příspěvků

Přidej příspěvek

Toto téma je starší jak čtvrt roku – přidej svůj příspěvek jen tehdy, máš-li k tématu opravdu co říct!

Ano, opravdu chci reagovat → zobrazí formulář pro přidání příspěvku

×Vložení zdrojáku

×Vložení obrázku

Vložit URL obrázku Vybrat obrázek na disku
Vlož URL adresu obrázku:
Klikni a vyber obrázek z počítače:

×Vložení videa

Aktuálně jsou podporována videa ze serverů YouTube, Vimeo a Dailymotion.
×
 
Podporujeme Gravatara.
Zadej URL adresu Avatara (40 x 40 px) nebo emailovou adresu pro použití Gravatara.
Email nikam neukládáme, po získání Gravatara je zahozen.
-
Pravidla pro psaní příspěvků, používej diakritiku. ENTER pro nový odstavec, SHIFT + ENTER pro nový řádek.
Sledovat nové příspěvky (pouze pro přihlášené)
Sleduj vlákno a v případě přidání nového příspěvku o tom budeš vědět mezi prvními.
Reaguješ na příspěvek:

Uživatelé prohlížející si toto vlákno

Uživatelé on-line: 0 registrovaných, 6 hostů

 

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032020 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý