Autor Zpráva
aDAm
Profil
Předpokládejme že máme aplikaci která se používá napříč státy a kontinenty. V této aplikaci se zakládají položky u kterých se definuje datum a čas. Samotný server má nastavenu časovou zónu na Londýn (php i db). Jak zpracovávat data?

Př.1: člověk z čr založí položku u které nastaví lokální datum, např.: 28.4.2014 14:30. V tento datum a čas bude třeba online vysílat nějaký pořad, nebo mu má někdo zavolat. Tuto položku si otevře člověk žijící v Londýně a tudíž by měl vidět datum: 28.4.2014 13:30. Jak postupovat?
* Časovou zónu zadavatele znám, vím že používá CET Praha. (aktuálně CEST)
* Server má nastaveno UTC (aktuálně nevím jak se server chová když se přejde na letní čas, zřejmě stále poběží na UTC).
* Je teda potřeba před uložením datum a času do db, tento čas převést na UTC a pak uložit?
* Jak jej pak znova uživateli zobrazit? Aby ten co jej založil videl stále korektně ted 28.4.2014 14:30
* Na datumové operace se používa \DateTime, datum je v db uloženo ve sloupci typu datetime
Kajman
Profil
A má to fungovat napříč různými databázemi? Nebo máte databázi, které práce s časovými pásmy není cizí?
aDAm
Profil
Databázový server mám ve vlastní správě takže je možné na něm nastavit prakticky cokoliv.
_es
Profil
aDAm:
Server má nastaveno UTC (aktuálně nevím jak se server chová když se přejde na letní čas, zřejmě stále poběží na UTC).
UTC nemá „letný“ a „zimný“ čas. Ak by nastala zmena, tak by nepracoval server správne, prípadne mu to treba nastaviť.

Najlepšie bude asi pracovať v databázei s UTC časom a zobrazovať a príjimať čas v miestnom čase návštevníka, prípadne mu umožniť aj pracovať s UTC časom.
Kajman
Profil
aDAm:
je možné na něm nastavit prakticky cokoliv

V tom případě bych zvážil PostreSQL.
aDAm
Profil
_es:
tak UTC je v podstatě "zimní" čas že. Jako měnit časové pásmo serveru podle datumu mě nepřipadá jako košér, nebo jsem pochopil špatně?

Kajman:
nope, db je mysql
Kajman
Profil
Tak v mysql bych asi také vše ukládal a vybíral v UTC a všechnu logiku převodu časů při zadávání a vypisovaní řešil přes php (může i spolupracovat javascript).
aDAm
Profil
Takže před uložením převést zadaný čas na UTC, uložit do db. Při načtení a zobrazení jej pak opět převést na časovou zónu uživatele? Jak správně řešit letní čas?
Joker
Profil
Nakolik vím, MySQL u uložených časů nerozeznává časové pásmo.
Takže asi nezbude než časy ukládat v UTC a převádět je. Případně by na převody šlo použít TZ_CONVERT.

aDAm:
tak UTC je v podstatě "zimní" čas že.
Časová pásma nerozlišují letní a zimní čas, naopak při přechodu na letní čas a zpět se mění časové pásmo dané země.
Třeba na Azorech je UTC letní čas.
Tím chci říct, že UTC je pořád UTC, rozdíl mezi letním a „zimním“ časem je, že ČR je normálně časové pásmo UTC+1 a během letního času UTC+2. Což by měl podchytit ten převod.
Když pomíjíme, že „zimní čas“ neexistuje, je „normální“ a letní; Letní čas je posun oproti „standardnímu“.
aDAm
Profil
No otázka je jak detekovat letní/normální čas? Dejme tomu že teď v letním čase založím událost co bude v listopadu tzn v zimním čase a naopak. Jak bezpečně zjistit zda je to CET či CEST? aby se pak dalo bezpečně z něj udělat UTC?
Kajman
Profil
Nepoužívejte CET a CEST, ale Europe/Prague.

<?php

$tz_database = new DateTimeZone('GMT');
$tz_user = new DateTimeZone('Europe/Prague');

$date =  new DateTime('2014-03-29 13:56:25', $tz_database);
$date->setTimezone($tz_user);
echo $date->format('Y-m-d H:i:s T'); 

echo "<br>";

$date =  new DateTime('2014-03-30 13:56:25', $tz_database);   
$date->setTimezone($tz_user);
echo $date->format('Y-m-d H:i:s T'); 

?>
aDAm
Profil
Kajman:
supr, takže když se použije přímo časové pásmo Europe/Prague, Europe/London či America/Denver tak bude datum korektně zobrazen ? Pokud chci data na serveru mít v GMT čase jakou zónu tedy na serveru nastavit? (php,mysql)
Kajman
Profil
GMT == UTC

Jedinou patálií je, pokud uživatel z ČR chce uložit akci třeba na 2014-10-26 02:34:56. Ten čas je v Europe/Prague 2x.
aDAm
Profil
Kajman:
díky moc za info.
No řekněme že to je akceptovatelný stav a budu doufat že k němu dojde maximálně 1 za 10 let ;)

Vaše odpověď

Mohlo by se hodit


Prosím používejte diakritiku a interpunkci.

Ochrana proti spamu. Napište prosím číslo dvě-sta čtyřicet-sedm:

0