| Autor | Zpráva | ||
|---|---|---|---|
| liborse Profil |
Dobrý den,
řeším jeden problém. Hodiny jsem hledal na Google, ale buď hledám špatně, či přesně nikdo můj problém neřešil. Řekl bych, že za A je správně, proto omluvte případně můj hloupý dotaz. Situace je taková, že od uživatel do formuláře vyplní datum a čas (ve formátu 08.05.2014 a čas jako 08:05), o správný formát se mi starají skripty a kontroluji to, nicméně v tom problém není. V odesílacím skriptu (je v PHP) tyto 2 hodnoty spojím a pomocí strtotime() vytvořím timestamp, který pak uložím do databáze. Dělám to tak kvůli snadnému řazení akcí v pozdějším výpisu (aby se řadilo nejen podle data, ale i podle hodin a nemuselo se řadit 2x, pokud by byly 2 časy v jeden den). Prostě s timestampem se mi pracuje dobře. A zde je právě možný problém. Co se stane, když dnes uživatel zadá dejme tomu datum 28.12.2013 v 8:00 a někdo si tento záznam prohlédne v zimním čase (když při zadávání byl letní čas)? Posune se čas o hodinu a nebo bude výpis správně. Jde mi o to, aby se při přechodu na zimní čas a obráceně, záznamy samovolně "neměnily" podle nastavení aktuální časové zóny. Možná je to triviální dotaz, ale nerad bych, aby někdo na akci dorazil o hodinu dříve či později, jestli mi rozumíte. Děkuji za odpověď. Dodám, že pracuji s PHP 5.3+, MySQL 5+, Apache, ( HTML, CSS, jQuery apod.).. EDIT: Ještě dodám, že datum z databáze vypisuji takto: StrFTime("%d.%m.%Y - %H:%M", $hodnota_timestampu_v_databazi) |
||
| peta Profil |
Pro sql prikazy:
http://dev.mysql.com/doc/refman/4.1/en//time-zone-support.html SET time_zone = timezone; Pro php prikazy: http://www.php.net/manual/en/function.date-default-timezone-set.php http://php.net/manual/en/timezones.php date_default_timezone_set() Nastavis si time zonu, podle ktere maji php nebo sql prikazy datum prepocitat a date / datetime ti cas spravne prepocita podle aktualniho casu serveru do casoveho razitka. Ted ses rozhodl ukladat cas. Mas nastaveny timezone +1 hodina. Podle serveroveho casu je datum, kdy se pro timezone +1 hodina nepripocitava nic. A tak ti cas prevede do casoveho razitka s (bez pripocitavani nebo odpocitanim 1 hodiny, ted nevim, ale proste spravne). Kdyz si toto razitko das zobrazit v case, kdy se hodina pripocitava, tak to je mu suma fuk, protoze on urcuje pripocitavani hodiny podle ulozeneho razitka a ne casu na serveru. |
||
| liborse Profil |
#3 · Zasláno: 24. 4. 2013, 13:26:11
To jsem potřeboval vědět. Díky!
|
||
| aDAm Profil |
#4 · Zasláno: 24. 4. 2013, 14:32:02
Jen taková drobná vsuvka. Proč to do DB neukládaš v datovém typu pro to určeném? Tedy DATETIME?
|
||
| Kajman Profil |
#5 · Zasláno: 24. 4. 2013, 14:51:20
aDAm:
„Proč to do DB neukládaš v datovém typu pro to určeném? Tedy DATETIME?“ Však problém zmiňuje, mysql neukládá u datetime časové pásmo a špatně tedy řadí podzimní posun o hodinu zpět, kdy může mít později vložený záznam v datetime starší čas. „aby se řadilo nejen podle data, ale i podle hodin a nemuselo se řadit 2x, pokud by byly 2 časy v jeden den“ |
||
| aDAm Profil |
#6 · Zasláno: 24. 4. 2013, 14:55:08
A tu unix time stampu to časové pásmo je? Měl jsem zato že unix time prostě jede v sekundách od svého počátku a to jaké datum/čas ti zobrazí při převodu nějakou časovou funkcí je dáno nastavením časového pásma serveru ne? Takže stejně by měl fungovat DB server.
|
||
|
Časová prodleva: 11 let
|
|||
0