26

I've been using the unix timestamp all my life.

I like it because it's easy to compare, it's fast because I store it as an integer. And since I'm using PHP, I can get any date/time format with date() function from the unixtimestamp.

Now, some people are saying that it's best to use the DATETIME format. But besides the more suited name, I don't see any advantages.

Is it indeed better to use DATETIME, if so, what are the advantages?

Thanks.

treznik
  • 7,955
  • 13
  • 47
  • 59

7 Answers7

34

If you store dates as Unix timestamps in the database, you're giving yourself the heavy lifting. You have to convert them to the formats you want to use, you have to do the calculations between date ranges, you have to build the queries to get data in a range. This seems counter-intuitive- surely your "programmer time" is best spent solving real problems?

It seems much better practice to store dates and times in the proper format that MySQL has available, then use the database functions to create the queries for the data you want. The time you would waste doing all the convertions and mucking about is massive compared to the afternoon spent reading (and understanding) 11.6 MySQL Date and Time Functions

Gav
  • 11,062
  • 7
  • 33
  • 35
  • 1
    I don't agree. Check my answer. – rockstardev Nov 07 '14 at 06:08
  • 2
    MySQL's DATETIME field lacks a timezone - always store dates in UTC (i.e. avoid NOW() - use UTC_TIMESTAMP()) otherwise you're going to get into a big mess as you try to internationalize your app and for *whatever* reason change your servers timezone. – jmc Sep 25 '15 at 20:22
9

I've also been a huge fan of the unix timestamp all my life. But I think the correct answer is: "depends". I recently did a single table database where I wanted to only list URLs. There would be a date field, but the date field is purely for sorting. I.e order by last_crawled. Which means I will never use any built-in date functions on that field. It is merely an easy way to get the oldest entries first and I will never apply date functions to this field. Now, had I made this a date field, I would have lost out on two things:

  1. A datetime field is twice the size of an integer
  2. Sorting by an integer is faster (not 100% sure of this, pending outcome of this question)

However, for another system I had to store transactional information. This made using internal mysql date functions possible which turned out to be very useful when we had to start doing reports.

Community
  • 1
  • 1
rockstardev
  • 13,479
  • 39
  • 164
  • 296
7

One advantage of using the MySQL date/time types is to be able to more simply use the date/time functions in MySQL.

The DATE type also has the advantage in that its only storing day, month and year so there is no space wasted or comparison complication that a seconds since epoch time would have for situations where you only cared about the day and not the time.

Personally I tend to use a database as just a dump for data so such functions are of little interest. In PHP I tend to just store the date in integer format for pretty much the reasons you state.

cletus
  • 616,129
  • 168
  • 910
  • 942
6

@Smita V, the inefficient query to which you refer is only so because you're applying your conversion function incorrectly to every table row, where you should apply it to the condition itself. So instead of

select col1,col2,colUnixdatetime from table where From_Unixtime(colUnixdatetime) between wtvdate1 and wtvdate2

, which converts every row on the table to compare it to the date you've got. You should use

select col1,col2,colUnixdatetime from table where colUnixdatetime between UNIX_TIMESTAMP(wtvdate1) and UNIX_TIMESTAMP(wtvdate2).

Doing it this way WILL use the appropriate table indexes.

@treznik a while ago I moved from a uts integer to a datetime or timestamp data types, for the reasons mentioned above, in that they're much easier to read and manipulate (I do quite a lot of direct table access). However I've lately started to re-think this approach for two reasons:

  1. There is no time zone location stored, so you're inferring the time zone based on your location. This may or may not be an issue for you.
  2. It ignores daylight saving time. So when the clocks go back at 2am, you will get 1:30am twice, and saying 2011-10-30 01:30 doesn't let you know this, whereas 1319938200 does. I don't think there's a native way in mysql to store date including time zone, except as a string (2011-10-30 01:30 BST).

I'm still trying to figure out the answer to this, myself.

Shawn Chin
  • 84,080
  • 19
  • 162
  • 191
hessodreamy
  • 309
  • 2
  • 7
  • Tell me about it, can't believe it was almost 3 years ago. I also switched to datetime not long after I started this thread, but never really got convinced it was the right choice. I constantly encounter the same problems you talk about and I still think the timestamp is the ultimate choice. But I guess sometimes, for the sake of getting stuff done, we need to give in and go with the most practical solution. – treznik May 31 '12 at 00:13
  • 1
    While datetime has no timezone, we store dates as UTC and convert to appropriate timezones either in the app layer or using convert_tz(). This solves both of your issues. – SuperGreg Dec 19 '14 at 23:32
  • 1
    In addition, I think datetime actually more reliable than timestamp, since I know the value is always exactly what I stored (in UTC), as opposed to timestamp where it is stored as UTC but converted to the server's timezone (which could change). – SuperGreg Dec 19 '14 at 23:43
3

Using database datetime is more efficient because every time you need to query you would need to apply from_unixtime() function to extract data from unix datetime col of the table. Using this function in where clause will completely ignore any index usage.

say my query is:

select col1,col2,colUnixdatetime from table where colUnixdatetime between wtvdate1 and wtvdate2

I would need to run:

select col1,col2,colUnixdatetime from table where From_Unixtime(colUnixdatetime) between wtvdate1 and wtvdate2

This above query will completely ignore any indexes, well there is no use of indexes here as they will never be used coz I will always have to use a function to get the real date time.

Any in-built function used on LHS of condition in a where clause would not use any indexes and if you have a HUGE table, your query will take longer.

Smita V
  • 31
  • 1
2

Easier maintenance is a plus. Seeing the actual date when you do:

select * from table where ...

is pretty nice.

Todd Gardner
  • 13,313
  • 39
  • 51
1

Easier to compare, and mysql provides a lot of date functions.

erenon
  • 18,838
  • 2
  • 61
  • 93