Autor Zpráva
Pavel Vodnář
Profil *
Ahojky, potřeboval by jsem malou radu - data se mi do DB ukládají ve formátu viz:
("Y-m-d");
ale potřeboval by jsem je pak z DB číst ve formátu viz:
("d.n.Y");
jak to převést? Děkuji
Pavel Vodnář
Profil *
Díky už sem na to přišel viz:

$datumtotime = strtotime($tvojedatum);
$novydatum = date ("d. m. Y", $datumtotime);
nightfish_
Profil *
Pavel Vodnář:
z DB číst ve formátu
SELECT DATE_FORMAT(`datum`, '%e. %c. %Y') FROM `tabulka`
Darker
Profil
Pavel Vodnář:
DB ukládají ve formátu viz:
Proč neukládáš time()?
nightfish_
Profil *
Darker:
Proč neukládáš time()?
Protože to nedává smysl?
Darker
Profil
Mě ano, pomocí funkce date lze čas libovolně formátovat. Navíc i chronologické řazení je pak hračka.
Kajman_
Profil *
Darker:
A ukládáte tak bez problémů i datumy narození čtyřicátníků či starších? Nebo datumy, které budou třeba za 30 let?
Darker
Profil
Stará data jsou problém, já bych to ukládal jako záporná čísla. A co se týče budoucnosti, o problému nevím ale musím se přiznat, že o problému uvažuji jen teoreticky, zatím jsem ukládal pouze časy víceméně aktuální.
Nicméně je to irelevantní, pokud jste totiž četli [#2], víte moc dobře, že tento problém pan Vodnář nemá.
DoubleThink
Profil *
Ukládat čas do databáze jako číslo je největší pitomost, jakou může programátor vymyslet.
Jan Tvrdík
Profil
DoubleThink:
Přestože ukládat datum jako číslo je prasárna a sám to tak nedělám, tak to rozhodně nepovažuji na pitomost. Ze své podstaty je timestamp mnohem přesnější časovou reprezentací než datetime, protože vyjadřuje samu podstatu času a to je skutečnost, že plyne. (V běžné praxi je to jedno, ale je dobré si tu uvědomit.) Netrpí tak problémy, které mají ostatní způsoby reprezentace času - časová pásma, letní a zimní čas, přestupná sekunda apod.
petr 6
Profil
Darker:
Navíc i chronologické řazení je pak hračka.
Jako by to při ukádání ve formátu YYYY-MM-DD bylo nepředstavitelně složité...

Mě ano, pomocí funkce date lze čas libovolně formátovat.
Jako by to při ukádání ve formátu YYYY-MM-DD nešlo
Darker
Profil
DoubleThink:
Dobrá dobrá, ale proč neřekneš proč. Je hezké, že jsi sto můj postup zhodnotit, ale moc jsi mi nepomohl. Prosím přibliž mi to.

petr 6:
Proč to dělat jednoduše, když to jde složitěji.

Musím upozornit, že mi sice nejen DoubleThink říká, že bych měl ukládat datum a ne čas, ale nikdo mi neřekl proč a já bych na to nerad přišel někdy, kdy bych toho litoval - např při chybě v programu.
Joker
Profil
Jan Tvrdík:
Netrpí tak problémy, které mají ostatní způsoby reprezentace času - časová pásma, letní a zimní čas, přestupná sekunda apod.
To se dá říct i naopak. Třeba pokud ukládám záznamy a u každého potřebuji vědět i v kolik hodin místního času byl uložen, musím si zvlášť uložit časové pásmo, korigované o letní/zimní čas.
Nebo třeba kolik sekund uplynulo od roku 1970? time() + 24. Kolik od roku 2000? time() + 2.

Darker:
ale proč neřekneš proč
To je jednoduché, jak by například vypadal kód pro rozdělení záznamů podle měsíců (kolik v lednu, únoru, atd.)?
Darker
Profil
Joker:
To je jednoduché, jak by například vypadal kód pro rozdělení záznamů podle měsíců (kolik v lednu, únoru, atd.)?
Dobře, máme tu jeden případ, kdy budeme potřebovat datum. (které se z čísla dostat dá, ale máme o řádek v programu navíc.)

Argument s místním časem je už zajímavější (vím že reagoval na jiné tvrzení), ale řešili jsem tu přece datumy, nebo ne? Nemluva o tom, že pokud budu data ukládat na jednom serveru, nemusí mě pásmo zajímat, pokud ho teda nemám na nějaké neposedné lodi.
Ale tady už jsem na tenkém ledě. Nebudu se už dál hádat, moje metoda byla označena za pitomost, přesvědčen jsem nebyl. Třeba na to časem přijdu sám. A nebo taky ne.
1Pupik1989
Profil
mě by to také zajímalo proč to je tak nehezké, ukládám totiž čas přes time() stejně jako Darker. S rozdělením na měsíce zase takový problém nebude. Je pravda, že bych mohl ukládat YYYY-MM-DD HH:MM:SS, ale tohle mi přijde tak nějak stejné.
Joker
Profil
Darker:
máme o řádek v programu navíc
Jasně, jde použít FROM_UNIXTIME čímž (se správným formátem) získám řetězec konvertovatelný na datum, ale to pak je úplně zbytečná práce které se můžu vyhnout prostě tím, že to budu mít uložené rovnou ve správném typu.
Navíc to platí i obráceně, když mám DATETIME a čistě náhodou bych někdy fakt potřeboval timestamp, taky se z toho dá dostat.

řešili jsem tu přece datumy, nebo ne?
Tak byť úplně nesouhlasím s DoubleThinkem v [#9] (programátor může udělat daleko větší pitomosti :) ), ukládat samotné datum číselně jako časové razítko mi přijde už fakt ulítlé.
Timestamp není datum ale čas, takže jednak to je plýtvání pamětí (4B timestamp uloží rozsah asi 136 let, 3B MySQL DATE uloží rozsah 9000 let), ale hlavně je problém už existence té „časové“ části- jeden den pak není jedna hodnota, ale sekvence 86400 hodnot.
Takže programátor buď musí zavést nějaký přepočet (nejspíš na 00.00:00 daného dne), který ale není vynutitelný na úrovni databáze, čímž vznikají hodnoty platné v databázi, ale neplatné v aplikaci. Druhá varianta je s tím počítat ve výběrech, čili místo „datum=den“ psát podmínky „(datum >= den_od) and (datum <= den_do)“, což jaksi popírá tu jednoduchost.

1Pupik1989:
Nejde o to to ukládat v nějakém formátu, ale ve správném datovém typu.
Prostě když databáze má datové typy pro datum a datum s časem, tak se datum, resp. datum s časem ukládá do nich a ne jako číslo.

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: