[gbl08ma]

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.

[bcrosby95]

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.

[pm90]

If MySQL did not have a TIME type, then I would agree with you.

The problem is that MYSQL does have such a type, and it seems to not be very useful for modern applications.

Maybe you could argue semantically that this is still a “feature” that’s missing. Perhaps. But it seems more like a defect, even if it is documented.

If arrays in Golang could only be 5 elements long (say), I think we would characterize that as a defect, even if it is well documented.

[craftinator]

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.