DB - timestamp vs int

Formátování děláte v aplikaci (např. v php)? Pak klidně používejte číselný datový typ a pokud použijete dostatečný rozsah (BIGINT nebo alespoň Unsigned INT) nebudete se muset za 17 let nervovat s omezením timestampu v mysql do 2038-01-19.

Jinak při dotazu na data ze sloupce timestamp, můžete použít funkci UNIX_TIMESTAMP, aby se vrátilo číslo. Také můžete přímo říci formát data funkcí DATE_FORMAT. Plus u timestampu i nastavenou časovou zónou sezení. Pokud se nepletu, tak časová zóna se nastavuje jen offsetem, takže když se v zimně zeptáte na čas z letního období, je to o hodinu posunuté. Např. v php je možné časové zóny řešit ladněji, takže bych se čísla nebál.

Zkuste se zeptat na ty úskalí toho, kdo to tvrdí.

Když do db uložíte číslo, vrátí Vám číslo. Úskalí v tom nevidím.

Naopak vidím úskalí v
- datetime - uloží čas dle aktuálního lokálního nastavení, ale není tam uložené, ve které časové zóně to bylo
- timestamp - mysql nemusí správně převést GMT na odpovídající lokální čas (např. v létě uložíte něco v poledne, když se v zimě zeptáte, kdy to bylo uloženo, bude to o hodinu dříve)

Časové typy mají i nějaké výhody, ale pokud formátujete timestamp až v aplikaci a umíte si do dotazů vypočítat timestampy při filtrování záznamů, tak na ukládání čísel nic špatného nevidím.

Ale nejsem si jistý, jestli se ptáte na mysql nebo ne. Zpracování timestampu různých databází může být různé.

kdeby45:
„jakto?“
Protože při ukládání TIMESTAMPu dochází ke konverzi do UTC z lokální časové zóny platné v okamžik uložení. Při čtení to samé opačně. Tudíž zjednodušeně se čas 19.20 v létě uloží jako 17.20, a při čtení v zimě se přečte 18.20.

kdeby45:
Tak jsem mysql a mariadb křivdil, pokud se timezóna nastaví jménem a ne jen offsetem, tak se to převádí normálně.
sqlfiddle.com/#!9/9eecb/123470

Myslím, že používat na datum a čas cokoliv jiného než časový datový typ je jednoznačná chyba. Bude to jen komplikovat použití indexů, časových SQL funkcí, bude to mást a znepřehledňovat ORM a jiné databázové nástroje.

Osobně na tohle používám UNIX TIMESTAMP a mám klid. Z problému Y2k38 si hlavu nedělám protože za 18 let budou aplikace a DB morálně zastaralé a budou nové.
Stejně jako tomu bylo s problémem Y2K. Taky někteří malovali čerty na zeď jak nám veškerá IT technika bude stávkovat. A to byl větší problém na úrovni systému než nějaký datum v DB. :)

Ukládat čas jako číslo je zhruba stejně vhodné jako ukládat číslo do varcharu. Jde to, funguje to a je to v devadesáti devíti případech ze sta prasárna.
Shrneme-li, na datum používej DATE, na čas DATETIME a na časovou značku samotného záznamu TIMESTAMP. Cokoliv ostatního je ve většině případů špatně.

N71:
Datetime je asi nejvhodnější, ale prostě není bezproblémový při některých situacích.

Přijde mi, že pokud chci dobře pracovat v mysql s různými časovými zónami dle preferencí uživatelů, není datetime vhodný typ, protože je tam jen datum a čas, ale není tam uložené, pro kterou časovou zónu ten čas platí. Jedině mít v aplikaci ošetřené, že do datetime dávám vždy čas v UTC a z něho to převádět, nebo si ručně dávat timezone do dalšího sloupce.

Ono v mysql je u datetime problém i v jednom časovém pásmu, pokud se přechází na letní čas. Lokálně uložený čas totiž pak neřadí správně
Zmena letného času na zimný (zmena tit. po Ch. skoku v čase)

Timestamp má dle mysql manuálu hranici použitelnosti 2038-01-19.

Osobně mám z Y2038 celkem obavy a to jsem neměl z Y2K skoro žádné :-)