Skip to content

Why MySQL’s DATETIME can and should be avoided

billauer.co.il
1 pointzeeone3 comments
On HN

Comments

Right, stop using those "complicated" built-in date processing functions and instead roll your own. What could possibly go wrong? Storing a number that's only meaningful when defining it somewhere outside of the database is much more fun! Finally you get to meet all your co-workers in person, at least all the junior developers who will stop by your desk to ask why there are these weird numbers in the date columns.

A junior developer who doesn't know about epoch time should not be given any tasks other than "bring more tea" and "go pickup the chinese food order".

Also, let me see your "complicated" built-in date processing functions convert a date from Gregorian calendar to Julian or Mayan. You'll always come down to using your own tools.

tldr: In this article from 2009, consider storing UTC plus the local timezone instead of the local server time when building applications that have users in multiple timezones. Use a time or a time offset as appropriate to capture a point in time (e.g. a birthday) or a timespan (e.g. the number of seconds this thing ran), resp.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.