The MySQL documentation suggests using it to store a time interval:
"The hours part may be so large because the TIME type can be used not only to represent a time of day (which must be less than 24 hours), but also elapsed time or a time interval between two events (which may be much greater than 24 hours, or even negative)." [1]
How is the author's usage incorrect? Sure there's a documented allowed range, but it seems to me that the complaint is about the poor size of the range relative to other SQL technologies.
"If we want to complain that MySQL has an utterly useless TIME datatype, and separately they really should have an INTERVAL datatype, then let's do that."
Uhh, done?
"The issue" is that MySQL has a TIME type that is goofy as all get-out, and this guy's friend had a bug that prompted him to look into the TIME type and find out how goofy it is. I don't recall him complaining that it's not in the docs (since that's where he looked it up). The bug was only a story, the thing that prompted him to look into it. Take a breath, this isn't StackOverflow (not that being rude and offended/butthurt is welcome there either).
The issue seems to be that the .NET core provider for MySQL that OP uses maps the .NET Timespan type to this MySQL TIME datatype. They probably didn't think this through.
MySQL not having a proper type to express time spans seems like a fault to me, and "poor design". Of course you can just use an integer for it, but that is a slippery slope, in the end you'll find that you can use strings or byte arrays for everything and you end up with no type system at all.
The surprise here is not that the type has limits but that they are so awkward and that there is no better strongly-typed alternative.
A missing feature is not the same thing as poor design. If you need time spans in your project it could be a fault, but every product has missing features and choosing a product that is missing features you want might be a poor decision - depending upon other tradeoffs you're making.
It seems like poor design to me, but more so on the .NET side than MySQL side. MySQL retaining backwards compatibility is sensible, though seems a bit awkward that they don't introduce a TIME_LONG type or similar that can hold more useful ranges. .NET just mapping a time span with a wider range down to MySQL's fairly limited range seems destined to cause problems.
>If we want to complain that MySQL has an utterly useless TIME datatype, and separately they really should have an INTERVAL datatype, then let's do that.
Well isn't this complaint basically the last paragraph of TFA verbatim?
The issue is that the authors expectations didn't match with reality, because he hadn't yet read the docs.
The moment the author wrote "I normally use PostgreSQL" I knew that this would devolve into a "MySQL Bad" even if it's well defined and documented behavior.
The author had no specific expectations. The author received a report of an error, investigated, found that MySQL's TIME did not match EF Core's expectations for a timespan (hence causing the error):
> for a brief moment I assumed the incorrection in this value was the hundreds of hours, as one could reasonably assume that maybe TIME values were capped at 24 hours, or that a different syntax was needed for values spanning multiple days
And then it turned out that wasn't the case and they basically got nerd-sniped by the issue into finding out why the type had such weird bounds.
I don't think there were any biases here. The research into the docs came first, and the title seems like the conclusion rather than the hypothesis.
Besides, I don't use databases all that much and I don't write blog posts either, but if I did, and I came across this issue, this might be the exact article I would write (except the liking Postgres thing).
No, it does not. What it does is explain why they are admittedly "not too experienced with MySQL" and didn't straight remember that obviously the range of MySQL's TIME type is '-838:59:59' to '838:59:59' so 960 would be out of range.
Also please don't staple dicks onto people, the author's gender is irrelevant to the article and it's very disturbing.
> Also see: the title of the article.
The title of the article, and the introduction you're quoting, follow from the article itself. Unless you're calling the author a liar and think they made up the entire thing just to bash mysql.
That the author ultimately considers the behaviour of MySQL's TIME type and its bounds "a WTF"… is entirely defensible.
