0

How to store current date in MYSQL in UNIX milliseconds like this date: 1388880000000?

Now I store this in datetime.

  • 2
    Don't. DateTime values should be stored as DateTime. Unless you have a really good reason for storing them otherwise (like for supporting date and time values outside of the min/max values of datetime), I would suggest to should leave it in a DateTime column. – Zohar Peled Feb 25 '18 at 13:04
  • `UNIX_TIMESTAMP` & `FROM_UNIXTIME` plus multiplication/division */1000 – dnoeth Feb 25 '18 at 13:06
  • Use Timestamp. See https://dev.mysql.com/doc/refman/5.7/en/datetime.html – Juan Feb 25 '18 at 13:07
  • So, you recommend to store date in datetime? And use SELECT format? –  Feb 25 '18 at 13:08
  • 1
    I've elaborated on my comment in an answer. Hope it helps. – Zohar Peled Feb 25 '18 at 13:57

1 Answers1

2

Don't. DateTime values should be stored as DateTime, unless you have a really good reason for storing them otherwise (like for supporting date and time values outside of the min/max values of DateTime), I would suggest to should leave it in a DateTime column.

You can always manipulate how you return them from the database during Select or in the presentation layer. To return the unix time from DateTime, MySql provides a built in method called UNIX_TIMESTAMP. To return the number of milliseconds, simply multiply by 1000, since the unix timestamp is the number of seconds since January 1st, 1970 (not including leap seconds). If you want to store unix time, you will have to use an int data type.

Please note that if you do store unix time instead of storing the actual DateTime value in a DateTime data type column, you will loose the ability to use all the datetime built in database functions easily. For instance, if you want to find out how many rows belong to a specific month, you will first have to translate the data from int to datetime, and only then you will be able to calculate that.

You will also lose accuracy (since unix time is inaccurate even on the 1 second resolution, because it ignores leap seconds).

So, to conclude - When the database offers you a data type that fits the data, don't go storing that data using a different data type. use the Date data type if you only want to store dates, the DateTime data type if you want to store datetime values, and the Time data type if you want to store a specific time in the day.

P.S.
When dealing with date time values, Especially if you have to deal with clients from multiple locations, ALWAYS store only UTC date times in your database, unless, of course, you want to go mad.

Zohar Peled
  • 79,642
  • 10
  • 69
  • 121
  • Excellent, if my case I have to use `datetime` and use `UNIX_TIMESTAMP` to get date in seconds or multiply this on 1000 to get in milliseconds. I got it. Thank you! –  Feb 25 '18 at 14:06
  • Do you know any DBMS which is not ignoring leap seconds, i.e. the difference between '2018-07-01 00:00:01' and '2018-06-30 23:59:59' is three seconds instead of two? – dnoeth Feb 25 '18 at 14:54
  • Glad to help :-). It's not that the DBMS is ignoring leap seconds, it's that [unix time by definition is ignoring them.](https://en.wikipedia.org/wiki/Unix_time#) – Zohar Peled Feb 25 '18 at 15:05
  • I know, but all DBMSes ignore it, too. If you got luck you can load `'2016-06-30 23:59:60'`, but then it displays as `'2016-07-01 00:00:00'` (of course both timestamps in my previous post should be 2016, not 2018). No DBMS I'm aware of will actually calculate the correct difference. – dnoeth Feb 25 '18 at 15:11
  • @dnoeth I know a lot of computer systems simply repeats the 59th second when leap second is applied, to avoid dealing with special case time validation. I don't know of any computer software that actually treat 23:59:60 as a valid time. – Zohar Peled Feb 25 '18 at 15:26
  • Teradata supports Standard SQL which allows two leap seconds, thus '2016-06-30 23:59:60' is accepted but the leap second is actuall ignored and when you add another second it will be '00:00:02' :-) – dnoeth Feb 25 '18 at 16:40
  • @dnoeth Thanks! This is what I love about this website - you always learn new things. – Zohar Peled Feb 25 '18 at 18:35
  • How do you lose accuracy? `DateTime` cannot represent the leap-seconds either, and `Timestamp` is internally just UNIX time anyhow. – Doin Nov 25 '18 at 00:28
  • You can't represent leap seconds but as far as I know they are not ignored - the current date time includes the leap seconds between now and January 1st 1970, while Unix time does not. – Zohar Peled Nov 25 '18 at 05:07