Timeline for Calculating time difference between 2 dates in minutes
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2022 at 15:48 | comment | added | James Stevens |
Not sure if they've corrected it yet, but when I last used UNIX_TIMESTAMP() it was only 32 bit (signed) - that meant it would not operate more than 68 yrs either side of 1970 (1902 to 2038) - may not be a problem just now, but then the millenium bug wasn't a problem in the 1980s
|
|
| Oct 10, 2012 at 16:46 | comment | added | Ilmari Karonen |
@Andrew: You're right, it should be INTERVAL 20 MINUTE. I can't edit my comment any more to fix it, but I can (and just did) edit the answer.
|
|
| Oct 10, 2012 at 16:44 | history | edited | Ilmari Karonen | CC BY-SA 3.0 |
deleted 1 characters in body
|
| Oct 10, 2012 at 15:52 | comment | added | Andrew Kozak |
@IlmariKaronen This fails for me if I use MINUTES, but works if I use MINUTE. Per the MySQL docs MINUTE is expected by DATE_ADD and DATE_SUB in ver 5.5. Does MINUTES work in other versions?
|
|
| Oct 3, 2011 at 15:49 | comment | added | Ilmari Karonen |
It might not be, if MySQL is smart enough, but in general, if you have an index on t.col, then t.col < func(const) ought to be faster than invfunc(t.col) < const because the DB can precalculate the right hand side and use the index.
|
|
| Oct 3, 2011 at 15:19 | comment | added | itsmeee | why do you think the rewritten condition is faster than the initial one? | |
| Oct 3, 2011 at 15:11 | comment | added | Ilmari Karonen |
I don't know is MySQL's optimizer is smart enough to do this by itself, but on general principle I'd rewrite the first condition as T.runTime < DATE_SUB(NOW(), INTERVAL 20 MINUTES).
|
|
| Oct 3, 2011 at 14:49 | history | answered | itsmeee | CC BY-SA 3.0 |