Stylizace DATE

Pavel Vodnář:
„z DB číst ve formátu“

Pavel Vodnář:
„DB ukládají ve formátu viz:“
Proč neukládáš time()?

Darker:
„Proč neukládáš time()?“
Protože to nedává smysl?

Mě ano, pomocí funkce date lze čas libovolně formátovat. Navíc i chronologické řazení je pak hračka.

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?

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á.

Ukládat čas do databáze jako číslo je největší pitomost, jakou může programátor vymyslet.

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.

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

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.

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.)?

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.

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é.

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.