3 ms·
I agree it's not a necessary change. But, on the other hand, how much compatibility would it really break? I cannot imagine much applications are dependent on M
by Sebb767 6y ago
I agree it's not a necessary change. But, on the other hand, how much compatibility would it really break? I cannot imagine much applications are dependent on MySQL throwing an error at 800-odd hours (and it would arguably be a very strange design decision).
- falcolas 6y ago> how much compatibility would it really break Probably only a few applications; but that's still too many. And backwards compatibility does matter. A change here means that some few dozen developers have to now troubleshoot a previously-stable application which now fails silently in odd corner cases.
- nytgop77 6y agothen create new type. time2 or datetime13 with improved behaviour and say in docs to prefer newer unless your specicaly know that you need old behaviour.
- toast0 6y agoHaving a type mean different things on different versions of the database is not good. If you want a new type that does new things, it should have a new name. If the old type is so bad, you could make an sql mode to blacklist it. Yes, that leaves a legacy of why should I use TIME2 or whatever instead of TIME, etc. That's the downfall of having a successful project over a long time frame and not having designed it perfectly at the beginning. See also UTF8 shouldn't be used in MySQL because it's dumb. But you can't change UTF8 to do the right thing, you have to have a new name that's better.
- Dylan16807 6y agoIt would be a huge change in behavior to fix utf8. Changing the limit from 838 to 999 wouldn't.
- erik_seaberg 6y agoMySQL is notorious for quietly guessing what you must have meant. Writers need to validate up front, and then try to read back what was actually written.