Comments on: Why MySQL’s (SQL) DATETIME can and should be avoided

By: Stanley

Stanley — Fri, 06 Sep 2024 07:50:44 +0000

Excellent! you saved my time,i was looking for that. thanks

By: Dan

Dan — Tue, 28 Apr 2020 14:50:46 +0000

Our company still stores some dates as unix timestamps in MySQL. It was convenient in the beginning, and still is, in some ways. But from a DB perspective, it just sucks doing queries, both in the outut and in the query you have to write. And now, our db talks to another DB that uses SQL dates everywhere. So we are constantly converting back and forth.

I would say everything is wrong about this post. None of the issues that are listed (all real issues) couldn’t be also solved with SQL dates using UTC. But the biggest issue is that MySQL doesn’t support 64-bit unix timestamps, which means if you need to use a future date after 2038, everything just breaks.

https://bugs.mysql.com/bug.php?id=12654

The author’s assurance that everything will be fixed before 2038 is surely true. But guess what? We need to use future dates now, not in 2038.

By: Shawn

Shawn — Sat, 21 Mar 2020 12:54:23 +0000

4. Doing querying for date ranges are MUCH easier
5. Reading is much easier when you do direct queries (if you ask why, you haven’t got into real systems, only kiddie play systems)

remember – SET MYSQL TO UTC !

By: Shawn

Shawn — Sat, 21 Mar 2020 11:55:40 +0000

Times have changed, and front-end backend, OS has changed.

RULES

1. mysql ALWAYS SET ON UTC
2. Datetime is good -> for obvious reasons once you really work on backend a lot – on update on create default values easy to set.
3. If you don’t know how to set your mysql to UTC, you should learn. Here is a start: https://stackoverflow.com/questions/19023978/should-mysql-have-its-timezone-set-to-utc
(Use google and search for more resources)

By: Obvious Guy

Obvious Guy — Sat, 07 Sep 2019 21:27:21 +0000

Always set MySQL (or any server) to use UTC exclusively. Problem solved. Simple.

You should never be storing any time data in a local time zone. Convert it on display if you have to.

By: Daniel

Daniel — Sat, 15 Jun 2019 01:38:30 +0000

This is silly stuff from someone with a narrow view of the world. I used to store everything in unix_timestamp() format, until I stopped. The reason is that when I’m using a DB browser like adminer I can’t decode the unix timestamps in my head. If I’m checking a login DB to see when someone logged in last, the unix timestamps are useless to me. Plus sometimes I want to just dump a DB without having to write a program to convert the timestamp. I can grep a date from the command line. There’s a lot of reasons to have a date in a DB that can be read by humans

PHP has strtotime() which converts just about anything to a unix timestamps, so it’s easy to convert or compare different format times.

By: Peter Backes

Peter Backes — Fri, 23 Jun 2017 11:17:12 +0000

Small correction to my message from yesterday, 15:26: The Note with example at in the MySQL documentation is not the right reference. NOW() would never generate ’2005-03-27 02:00:00′ because the clock jumps from 01:59:59 to 03:00:00. Therefore the duplicate values in this case are not the problem. The problem is that NOW() will twice have the value ’2017-10-29 02:00:00′, in CET/CEST. Compare SELECT UNIX_TIMESTAMP(’2017-10-29 01:59:59′)-UNIX_TIMESTAMP(’2017-10-29 02:00:00′); That is, 2017-10-29 02:00:00-03:59:59 CEST will be incorrectly stored as 2017-10-29 02:00:00-03:59:59 CET.

One further improvement to what I said: If you use LPAD(TIME_FORMAT(TIMEDIFF(NOW(), UTC_TIMESTAMP),’%H:%i’),6,’+') when storing the timezone for disambiguation, you can conveniently use it with CONVERT_TZ().

By: Peter Backes

Peter Backes — Thu, 22 Jun 2017 14:41:05 +0000

Addendum: Why not simply use UNIX_TIMESTAMP() instead? That prevents the ambiguities of NOW().

Note also that if one insists on storing a DATETIME NOW(), one can additionally store the current timezone for disambiguation: TIME_FORMAT(TIMEDIFF(NOW(), UTC_TIMESTAMP),’%H%i’)

By: Peter Backes

Peter Backes — Thu, 22 Jun 2017 13:26:35 +0000

You say “The short and not-so-clever answer is that you could always use MySQL’s UNIX_TIMESTAMP( NOW() ) for this.” Please don’t do this! UNIX_TIMESTAMP(NOW()) still uses NOW(), which means the UNIX timestamp you generate may be wrong. See the Note with example at https://dev.mysql.com/doc/refman/5.7/en/date-and-time-functions.html#function_unix-timestamp in the MySQL documentation.

By: Kamil Mikolajczyk

Kamil Mikolajczyk — Mon, 02 Jan 2017 09:56:16 +0000

I am working on a project where we need to store employee’s working hours. First, we started with timestamps, and the for example: we have an employee in New York (GMT-5), Berlin (GMT+1) and Sydney (GMT+10), they all work from 8am to 4pm

Here are the timestamps of their start of work for today:
Berlin: Mon Jan 02 07:00:00 UTC 2017 1483340400000
New York: Mon Jan 02 13:00:00 UTC 2017 1483362000000
Sydney: Sun Jan 01 22:00:00 UTC 2017 1483308000000

I want to query for all employees who worked today (date-wise)

SELECT * FROM `logged_work` WHERE timestamp_start >= ’2017-01-02′

and with timestamps I am getting only 2 results, mysql treats Sydney’s time as yesterday.

DATETIME columns were only option to solve it