为何数据库要将TIME与DURATION设为独立类型而非带范围约束的DURATION

二者分开设计的核心原因可以归纳为以下几点：

• 语义本质完全不同，是两种维度的时间概念
  TIME的本质是「一天内的时刻点」，比如18:30代表下班的时间点，不是长度；DURATION（SQL标准里正式命名为INTERVAL）的本质是「时间间隔/时长」，比如2.5小时代表会议开了多久。二者根本不是同一类数据的不同取值范围，不存在包含关系。如果强行合并成带范围约束的DURATION，会出现二义性：同样存了12:00，你无法判断它代表中午12点，还是12小时的时长，业务逻辑极容易出语义错误，这类错误靠取值范围约束完全防不住。
• 运算规则差异极大，分开实现能避免大量无效校验
  两种类型支持的合法运算完全不一样：
  • TIME + DURATION = 新的TIME（比如9点加3小时是12点，合法）
  • DURATION + DURATION = 新的DURATION（比如2小时加3小时是5小时，合法）
  • TIME + TIME 完全没有逻辑意义
    如果合并类型，所有运算前都要额外做语义校验，性能低不说还容易漏判。
• 存储和性能优化的需求不同
  TIME的取值范围固定是0~24小时，用3字节就能存下，排序、比较逻辑非常简单，不需要处理负数、跨天、闰年等场景；而DURATION要支持正负、最长几年甚至几十年的时长，需要更大的存储空间，运算时还要处理月份天数差异、闰年等特殊逻辑。分开实现的话两种场景都能拿到最优的存储效率和运算性能，不会为了小范围的时刻场景付出不必要的开销。

你观察到的MySQL、SQL Server未单独提供DURATION类型属于数据库的实现选择，并不是标准导向：SQL标准本身就明确区分了时刻类类型和间隔类类型，PostgreSQL的两种类型实现就是严格对齐SQL标准的。
至于你提到的类似VARCHAR(n)的参数化范围方案，实际上不少数据库的DURATION/INTERVAL类型本身就支持加范围约束，比如你可以给INTERVAL加检查约束让它的取值不能超过24小时，但这只是用来约束「时长的最大长度」，依然不能替代TIME的语义作用。

内容的提问来源于stack exchange，提问作者David542