Hacker News new | comments | show | ask | jobs | submit login
Why MySQL’s DATETIME can and should be avoided (billauer.co.il)
1 point by zeeone 2260 days ago | hide | past | web | favorite | 3 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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact