The failings of MySQL’s curtime
function
The MySQL curtime
function has (at least) the following issues:
- 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.)
- 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.)
- 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.
- 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.)
- 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.
P.S. I recently created a nerdy privacy-respecting tool called When Will I Run Out Of Money? It's available for free if you want to check it out.