The failings of MySQL’s curtime function

The MySQL curtime function has (at least) the following issues:

  1. The function returns the current time as a number i.e. the time quarter past 8 would be returned from the function as the number 201500. (So if you subtract one from such a number you get 201499 which has no meaning.)
  2. The function only returns this if you use it in an "integer context", i.e. (x+0) causes x to be evaluated to an integer. (Otherwise it produces a string in a different format.)
  3. At some point the function was changed not to return an integer but to return a decimal with 6 decimal places. As far as I can tell these 6 decimal places are always zero. The example in the documentation also supports this experience.
  4. There is no way to specify a timezone. When going from a point in time (e.g. unix time or simply the concept of "now") to/from an external format (hours, minutes, year, ...) you must always specify a timezone. The concept of the "default timezone" should just be eradicated and deleted from the world. If I had a time-machine, the first thing I would do is go back and prevent this concept's creation. (The user must see the data in their timezone, which on a web application needn't be the same as the server's. And if you are writing a desktop application, you need to decide explicitly to use the user's timezone, as not all data might be for the user, e.g. data from a server or database.)
  5. I don't really think the name of the function is very good (saving characters by abbreviating the name, but why?)

Why would you ever use a function? Why would you ever add it to your database product. *Shakes Head*

I welcome feedback of the form "this is an amazing function, I've used it my application and it fitted my need exactly". I do really welcome this. Please don't hold back.

Related: curdate, now.

This article is © Adrian Smith.
It was originally published on 7 Jul 2011
More on: FAIL | MySQL | Language Design