Transfer: https://blog.csdn.net/yzsind/article/details/8831429
Today saw a microblogging Rinchen students, mentioned erroneous results mysql date of subtraction, not how to pay attention to before, so test it, found that really pit father, it is easy to step on mine, so finishing blog to remind everyone.
Look at the phenomenon of the following error, correct Article 1, Article 2,3 t2-t1 is incorrect:
mysql> select t1,t2,t2-t1 from mytest;
+---------------------+---------------------+-------+
| t1 | t2 | t2-t1 |
+---------------------+---------------------+-------+
| 2013-04-21 16:59:33 | 2013-04-21 16:59:43 | 10 |
| 2013-04-21 16:59:33 | 2013-04-21 17:00:33 | 4100 |
| 2013-04-21 16:59:33 | 2013-04-21 17:59:35 | 10002 |
+---------------------+---------------------+-------+
3 rows in set
All test scripts as follows:
--创建表
mysql> CREATE TABLE mytest (
t1 datetime,
t2 datetime
);
Query OK, 0 rows affected
--插入测试记录
mysql> insert into mytest(t1,t2) values('2013-04-21 16:59:33','2013-04-21 16:59:43');
Query OK, 1 row affected
mysql> insert into mytest(t1,t2) values('2013-04-21 16:59:33','2013-04-21 17:00:33');
Query OK, 1 row affected
mysql> insert into mytest(t1,t2) values('2013-04-21 16:59:33','2013-04-21 17:59:35');
Query OK, 1 row affected
--验证结果
mysql> select t1,t2,t2-t1 from mytest;
+---------------------+---------------------+-------+
| t1 | t2 | t2-t1 |
+---------------------+---------------------+-------+
| 2013-04-21 16:59:33 | 2013-04-21 16:59:43 | 10 |
| 2013-04-21 16:59:33 | 2013-04-21 17:00:33 | 4100 |
| 2013-04-21 16:59:33 | 2013-04-21 17:59:35 | 10002 |
+---------------------+---------------------+-------+
3 rows in set
The actual time is mysql subtraction is made an implicit conversion operation, the conversion time of an integer, but not with unix_timestamp conversion, but directly to the year, month, day, hour put together, such as 2013-04-21 16:59 : 33 directly into 20,130,421,165,933, because of the time instead of a decimal, so the final result does not make sense, which also contributed to the results of pit father appears above.
mysql> select t1,
t2,
convert(t1, UNSIGNED INTEGER) ct1,
convert(t2, UNSIGNED INTEGER) ct2,
t2-t1,
convert(t2, UNSIGNED INTEGER) -convert(t1, UNSIGNED INTEGER) diff0
from mytest;
+-------------------+-------------------+--------------+--------------+-----+-----+
|t1 |t2 |ct1 |ct2 |t2-t1|diff0|
+-------------------+-------------------+--------------+--------------+-----+-----+
|2013-04-21 16:59:33|2013-04-21 16:59:43|20130421165933|20130421165943| 10| 10|
|2013-04-21 16:59:33|2013-04-21 17:00:33|20130421165933|20130421170033| 4100| 4100|
|2013-04-21 16:59:33|2013-04-21 17:59:35|20130421165933|20130421175935|10002|10002|
+-------------------+-------------------+--------------+--------------+-----+-----+
3 rows in set
To get the correct time subtraction second value, the following three methods:
. 1, TIME_TO_SEC (timeDiff (T2, T1)),
2, TIMESTAMPDIFF (SECOND, T1, T2),
. 3, UNIX_TIMESTAMP (T2) -unix_timestamp (T1)
--测试脚本
mysql> select t1,
t2,
t2-t1,
time_to_sec(timediff(t2, t1)) diff1,
timestampdiff(second, t1, t2) diff2,
unix_timestamp(t2) -unix_timestamp(t1) diff3
from mytest;
+---------------------+---------------------+-------+-------+-------+-------+
| t1 | t2 | t2-t1 | diff1 | diff2 | diff3 |
+---------------------+---------------------+-------+-------+-------+-------+
| 2013-04-21 16:59:33 | 2013-04-21 16:59:43 | 10 | 10 | 10 | 10 |
| 2013-04-21 16:59:33 | 2013-04-21 17:00:33 | 4100 | 60 | 60 | 60 |
| 2013-04-21 16:59:33 | 2013-04-21 17:59:35 | 10002 | 3602 | 3602 | 3602 |
+---------------------+---------------------+-------+-------+-------+-------+
3 rows in set
The problem in 2003 was the feedback in the version mysql4.0, but are not considered to be official mysql bug, because they believe that mysql does not support time direct subtraction operation, should be handled with special functions, it has not been amended. But I think this can easily lead to the wrong, either directly error, or display the correct results.