| Autor | Zpráva | ||
|---|---|---|---|
| ajajaj Profil |
#1 · Zasláno: 4. 12. 2009, 13:36:19
ahoj, právě jsem narazil na záhadu s výpisem strftime, datum mám vložený v db jako timestamp.
echo strftime("%Y-%m-%d", strtotime($kdy)) mi vypíše ve tvaru 2009-den???-měsíc??? už jste se s tím někdo setkal? vždycky jsem měl za to, že by to měl být formát year-month-day... |
||
| DoubleThink Profil * |
#2 · Zasláno: 4. 12. 2009, 14:49:37
Vzhledem k tomu, že %m = Two digit representation of the month a %d = Two-digit day of the month (with leading zeros), musí řetězec %Y-%m-%d vracet rok-měsíc-den. Chyba bude jinde, například už v timestampu.
A mimochodem, ukládat čas do databáze jako číslo je neospravedlnitelná prasárna. |
||
| ajajaj Profil |
#3 · Zasláno: 4. 12. 2009, 18:25:02 · Upravil/a: ajajaj
hm, tak takhle to není, to datum tam ukládá přímo mysql, current timestamp on update... (server je v usa s časovým posunem -25200)
v tom problém není a není to taky žádná prasárna důvod proč to řeším je ten, že potřebuji následující formát rok-měsíc a nic jiného, takže jsem chtěl aby %Y-%m napsalo 2009-12 ale neděje se tak. samozřejmě mě napadlo to %m vyměnit za %d když to vrací měsíc, jenže mi není jasné proč se to tak děje a jestli to tak bude i do budoucna. pro mě je sice důležitý výsledek, ne jak ho dosáhnu, ale zároveň musím mít jistotu, že způsob jeho dosažení je spolehlivý... proto to chci pochopit. |
||
| Majkl578 Profil |
#4 · Zasláno: 4. 12. 2009, 19:04:43
DoubleThink:
„A mimochodem, ukládat čas do databáze jako číslo je neospravedlnitelná prasárna.“ Proč? |
||
| ajajaj Profil |
#5 · Zasláno: 6. 12. 2009, 21:06:21 · Upravil/a: ajajaj
DoubleThink:
takhle to vypada v db 
takhle vypada vysledek php 
a takhle kod pro řádek "id objednávky"... $id_kdy=strftime("%Y-%m-%d", StrToTime($kdy)); |
||
| Davex Profil |
#6 · Zasláno: 6. 12. 2009, 21:47:40
Co je přesně obsahem proměnné $kdy? Datum objednávky je správně - jak vypadá kód pro jeho vytvoření?
|
||
| AM_ Profil |
#7 · Zasláno: 6. 12. 2009, 23:32:52
ajajaj:
a jakým způsobem vypisuješ "datum objednávky"? protože to se vypisuje dobře, tak bych se inspiroval tam. nebo si můžeš zjednodušit život a datum rozparsovat přes:
$date = explode(' ', $kdy); //rozdeli RRRR-MM-DD HH:MM:SS na datum a cas
$date = $date[0];
to bude skoro jistě fungovat, ale není to moc čisté řešení; ještě bych si zkontroloval, zda se opravdu všude předává datum v takovém formátu, v jakém chceš. Majkl578: > „A mimochodem, ukládat čas do databáze jako číslo je neospravedlnitelná prasárna.“ > Proč? nedorozumění bude asi v tom, že DoubleThink to pochopil tak, že má uložený TS jako INT(), což je opravdu specialita začátečníků, ale on je uložený asi jako datový typ TIMESTAMP (já také raději DATETIME, ale TIMESTAMPu těžko co vytknout). |
||
| Leo Profil |
#8 · Zasláno: 6. 12. 2009, 23:41:25
"ale TIMESTAMPu těžko co vytknout"
Snad až na to - pokud mluvíme o MySQL - že ho db server automaticky aktualizuje jak při vložení záznamu, tak při jeho UPDATE, takže dávat tam info o okamžiku objednávky apod. je podle mě blbost. Leo |
||
| Aleš Janda Profil |
#9 · Zasláno: 7. 12. 2009, 00:06:48 · Upravil/a: Aleš Janda
Leo:
> "ale TIMESTAMPu těžko co vytknout" Snad až na to - pokud mluvíme o MySQL - že ho db server automaticky aktualizuje jak při vložení záznamu, tak při jeho UPDATE Takto se chová pouze pokud má nastaveno ON_UPDATE_CURRENT_TIMESTAMP. Standardně ne. AM já také raději DATETIME Typ DATETIME jsem používal také, ale pouze do té doby, než jsem zjistil, že nerozlišuje rozdílné/stejné časy při změně letního času (nevím, jak mu říci „tenhle čas je letní/zimní“), což pak dělá bordel. Navíc také neobsahuje údaj, v jakém časovém pásmu je tento čas platný a MySQL takový typ neumí převést automaticky do jiného časového pásma. Nebo jsem nenašel jak. TIMESTAMP se mi proto zdá pro „časové známky“ o moc lepší, DATETIME se hodí jen na vágní údaj o čase, na který se má dívat spíše člověk než jej zpracovávat stroj. EDIT: Výjimečně používám jako časový údaj i typ double, a to tehdy, když chci čas uložit s přesností větší než 1 sekundu. |
||
| nightfish Profil |
#10 · Zasláno: 7. 12. 2009, 07:50:49
ajajaj:
> a takhle kod pro řádek "id objednávky"... > $id_kdy=strftime("%Y-%m-%d", StrToTime($kdy)); proč to neudělat hned v mySQL? SELECT DATE_FORMAT(`kdy`, '%Y-%m-%d') |
||
| ajajaj Profil |
#11 · Zasláno: 8. 12. 2009, 09:40:59
jejda, už jsem myslel že to zapadne... děkuji všem za rady, dopracovali jste se/mne k výsledku
používám prostě typ timestamp protože je k tomu určený a zatím jsem nezjistil jediný rozumný důvod proč tak nečinit, stejně tak jako používám tag table pro tabulku ;) ano. mám to opravdu ON UPDATE CURRENT_TIMESTAMP a zjistil jsem, že následný (jediný možný) update sloupce "stav" neovlivní už uložený timestamp, takže jej s čistým svědomím využívám $kdy=StrFTime("%d/%m/%Y", strtotime($row['kdy'])+25200); - je tam časový posun chybu jsem eliminoval, nastala právě úpravou toho $kdy, pokud formátuji čas na potřebný tvar rovnou z dotazu na db tak to vyleze správně, netušil jsem, že nemůžu upravovat už jednou formátované |
||
| Leo Profil |
#12 · Zasláno: 8. 12. 2009, 10:45:38
"Typ DATETIME jsem používal také, ale pouze do té doby, než jsem zjistil, že nerozlišuje rozdílné/stejné časy při změně letního času (nevím, jak mu říci „tenhle čas je letní/zimní“), což pak dělá bordel."
Podle me je nejmenší bordel ukládat tam (i jinde na počítači) kalendářní údaj v co nejjednodušší podobě, tedy pokud možno kontinuální řadě (t.j. nepřecházet na letní čas, třeba UT). Pracovat s řadou, kde se může stejný údaj objevit dvakrát a jindy zase ani jednou (v te hodině, kdy dochází ke změnám na letní/zimní) je šílenost. Dost na tom, že kalendářní systém je už tak dost pošahaná záležitost plná výjimek. Leo |
||
|
Časová prodleva: 14 let
|
|||
0