Dotaz: Ukládání budoucích časů vs. letní čas

[Josef Kufner]

Zrovna píšu jednu aplikaci, se kterou budou pracovat lidé v různých časových pásmech současně. Původně jsem si říkal, že bude stačit ukládat všechny časy v UTC a podle aktuálního nastavení časové zóny klienta ho správně přepočítávat. To lze celkem lehce v MySQL udělat použitím sloupců typu TIMESTAMP a nastavováním časového pásma per session (SET time_zone = '...').

Ovšem narazil jsem na malou zákeřnost: Pokud uložím do databáze v zimě čas, který je v létě, tak až se na tento záznam podívám v létě, bude o hodinu posunut, protože jsem mezitím změnil časové pásmo z +1:00 na +2:00.

Takže to takle jednoduché nebude.

Jak tedy na to? Nevíte o nějakém ověřeném a jednoduchém způsobu používaném v kalendářích?

Na webu je na toto téma hromada textu, ale prakticky všechny jsou dosti pochybné a často i zjevně chybné. Dokonce jsem našel i diskuze o chybě v Google Calendar týkající se letního času.

Moje aplikace je klasické PHP 5.3 + MySQL, ale to není až tak podstatné.

---

---

Odpovědi

[Filip Jirsák]

Něco je špatně. Buď to vy špatně používáte, nebo je chyba v MySQL. Když máte čas s časovou zónou, je jeho převod do jiné časové zóny vždy jednoznačný a není možné, aby se to přepočítávalo jednou správně a jednou špatně podle toho, zda je léto nebo zima. Letní a „zimní“ čas není nic jiného, než dvě časové zóny, mezi kterými se v konkrétní čas přepíná, a které představují pro danou oblast výchozí zónu, pokud se uvede čas bez uvedení zóny.

Jinak v dokumentaci typů MySQL nevidím nic o časových zónách (že mě to u MySQL ani nepřekvapuje…), v MySQL Server Time Zone Support se píše, že timestamp se vždy ukládá v UTC a převádí se do aktuální časové zóny. Začal bych tedy tím, že se podíváte pomocí mysql klienta do databáze, zda tam ty časy máte správně a zda se správně převádí, když nastavíte různé časové zóny. Druhá věc je pak ještě zkontrolovat, jak se to chová v PHP, zda vám to náhodou nepřevádí mezi časovými zónami ještě podruhé.

[Jendа]

Podle mě máš chybu v tom, že v zimě paušálně ode všech ukládaných časů odečítáš 2 a ke všem zobrazovaným přičítáš 2 a v létě to samé s 1. Správně bys měl nejdřív posoudit, jaký bude v tom ukládaném datu platit čas, a podle toho to teprve přepočítat (tj. když v lednu ukládám červenec 14 hodin, do databáze se uloží 12 hodin). Jediný problém, který mě napadá, je, jak se má aplikace zachovat, když jí někdo zadá v lokálním čase ten_podzimní_den 2:30.

[Filip Jirsák]

Pokud tam nějaké hodiny přičítá nebo odčítá, je problém v tom přičítání/odčítání 13:00 TZ+2:00 == 12:00 TZ+1:00 == 11:00 UTC, žádné přičítání nebo odčítání není potřeba. Akorát je potřeba počítat s tím, že uživatel očekává časovou zónu platnou v době zadávaného času, ne aktuální – takže je potřeba časovou zónu přepínat podle zadávaného/čteného data, ne podle aktuálního data. Tj. pokud zadávám nebo čtu datum a čas v prosinci, musím nastavit časovou zónu SEČ, bez ohledu na to, zda je zrovna aktuální SEČ nebo SELČ. Při zadávání času mezi 2:00 a 3:00 při přechodu z letního času na standardní je asi potřeba se uživatele na časové pásmo dotázat, protože to nijak nevyvěštíte.

[Jendа]

Akorát je potřeba počítat s tím, že uživatel očekává časovou zónu platnou v době zadávaného času, ne aktuální – takže je potřeba časovou zónu přepínat podle zadávaného/čteného data, ne podle aktuálního data.

Jo, o to mi právě šlo. Jestli MySQL má tohle už nějak vyřešené, pak není co řešit. Z dotazu jsem nabyl dojmu, že si to přepočítávání píše sám.

[Josef Kufner]

Zatím ještě nepíšu (a ani nechci). Zjišťuju, jak se to dělá správně a trošku experimentuju.

Zatím jsem ve stavu, kdy v PHP i MySQL nastavuju zónu na něco ve stylu "Europe/Prague" a používám sloupce typu TIMESTAMP. Ale nevím, zda to stačí a jestli tam nejsou schované nějaké problémy...

[Filip Jirsák]

Nastavením časové zóny v PHP a MySQL ale určujete časovou zónu po aktuální čas. Vy ji ale potřebujete převádět vzhledem k datu a času, který ukládáte nebo zobrazujete. Když použijete aktuální časovou zónu, dopadne to tak, že uživatel teď zadá něco na prosinec 12:00 až 13:00, ale použije se aktuální časová zóna (tj. středoevropský letní čas), takže se to převede na 10:00 až 11:00 UTC. Až si to v prosinci zobrazí, bude aktuální „zimní“ čas a zobrazí se to jako 11:00 až 12:00 SEČ. To ale není chování, které uživatel očekává.

[Josef Kufner]

Já vím, proto tady tenhle dotaz je

[Filip Jirsák]

V tom případě ale nevím, na co se ptáte.

[Sten]

Nevím konkrétně u PHP, ale MySQL a naprostá většina rozumných systémů nastavuje zónu geograficky a potom to funguje dobře pro zimní i letní čas, tj. pokud v létě použijete 24. prosince 13:00, bude to 12:00 UTC, a naopak pokud v zimě použijete 24. červen 14:00, bude to 12:00 UTC.

[Filip Jirsák]

A pokud použiju 30. října 2011 2:30? Hádání časové zóny bez nápovědy uživatele obecně nemůže fungovat. Proto mají databáze, knihovny atd. pracovat vždy s dvojicí čas + časové pásmo, a pokud chce někdo časové pásmo hádat, měla by to dělat ta aplikace, která komunikuje s uživatelem. Ta jediná má dost informací a může se v případě potřeby zeptat.

[Michal Kubeček]

Pokud je řeč o časové zóně, tak ta už v sobě nese i informace o případném letním a zimním čase.

[Filip Jirsák]

No právě. Takže teď uživatel zadá čas v SELČ, a v prosinci se mu zobrazí v SEČ, tedy o hodinu posunutý – když uživatel čas zadával, předpokládal totiž, že jej zadává v SEČ. Je tedy logické, aby aplikace uživateli vyšla vstříc a ten předpoklad splnila.

[Michal Kubeček]

Jen pokud je aplikace špatně napsaná. Pokud je napsaná správně, definice časové zóny obsahuje i informaci o tom, jaký je v daném okamžiku offset oproti UTC, takže se správně převede jak aktuální čas, tak jakýkoli čas v minulosti nebo budoucnosti (samozřejmě za předpokladu, že mezitím nedojde ke změně pravidel).

[Filip Jirsák]

Asi každý myslíme něco jiného časovou zónou. Já píšu o těch časových zónách, které jsou definovány posunem od UTC, takže třeba SEČ (+1 h.) nebo SELČ (+2 h.). Vy zřejmě píšete o časové zóně Evropa/Praha, která může být SEČ nebo SELČ, podle toho jak kdy.

Problém je právě s určením toho časového okamžiku. Časový okamžik je určen právě časem a časovou zónou – když časová zóna chybí, může si aplikace něco domýšlet, ale to nebude vždy fungovat. I pokud dáme aplikaci také datum a aplikace bude mít pro daný rok správné údaje o přechodu na/z letní čas, pořád tam zbývá ta hodina při přechodu zpět na sluneční čas, kdy datum, čas a geografická časová zóna nestačí.

[Michal Kubeček]

Asi každý myslíme něco jiného časovou zónou.

Očividně. Ale pokud se v souvislosti s unixovými systémy používá termín timezone (časová zóna), myslí se tím téměř vždy to, o čem mluvím já.

pořád tam zbývá ta hodina při přechodu zpět na sluneční čas, kdy datum, čas a geografická časová zóna nestačí.

Proto se také jako interní reprezentace používá ta vyjádřená pomocí time_t, která tímto problémem netrpí. A proto funkce mktime() v tom jednom speciálním případě přihlíží i k hodnotě položky tm_isdst; protože ale tento speciální případ (u většiny zón - z těch, které vůbec nějaký letní čas mají) pokrývá přibližně jednu setinu procenta roku (navíc pečlivě vybranou tak, aby se toho dělo pokud možno co nejméně), nikdo to obvykle moc neřeší.

[Michal Kubeček]

Ten časový okamžik se prostě musí převádět na interní reprezentaci jako celek - mimo jiné i proto, že pravidla pro letní čas se čas od času mění. Standardní knihovní funkce mktime() a localtime() resp. localtime_r() se o to postarají, otázkou jen je, jestli je autor software použije nebo jestli se spolehne na lidovou tvořivost.

[Sten]

Nezadávejte zóny absolutně, ale geograficky:

SET time_zone='Europe/Prague'

Potom to funguje dobře.

[Josef Kufner]

Díky. Na tohle je potřeba importovat do MySQL data o zónách, což jsem předtím nějak minul...