部分Linux时间相关API被标记为弃用/废弃的原因是什么？

Linux时间API弃用决策背后的核心原因 #

这些API的弃用和保留是POSIX标准演进、API设计缺陷、兼容历史场景三个因素共同作用的结果，和精度高低没有直接对应关系：

1. 为什么stime()被弃用，time()没有被弃用？

• 两个API的定位完全不同：time()是C标准从诞生之初就规定的基础秒级时间获取接口，兼容性极强，几乎所有类Unix系统都原生支持，接口设计简单无历史包袱，仅需一个可选的time_t指针作为参数，大量不需要高精度时间的场景（比如秒级日志打印、业务时间戳生成）都依赖它，使用范围极广，完全没有弃用的合理性。
• stime()是用于设置系统时间的接口，本身设计存在明显局限性：仅支持秒级时间设置，无法满足更高精度的时间调整需求；也不支持指定不同时钟源（比如单调时钟、进程专属时钟等），所有功能都可以被支持纳秒级精度、可指定时钟ID的clock_settime()完全覆盖，因此被标记为弃用。

2. 为什么精度更高的gettimeofday()被标记为obsolete，反而time()被保留？

• gettimeofday()本身存在多处设计缺陷：首先它返回的微秒级精度已经无法满足当前高时序场景的需求，现在工业界通用纳秒级时间精度；其次它默认只能获取系统实时时钟（CLOCK_REALTIME）的时间，无法获取不受系统时间跳变影响的单调时钟等其他时钟源的时间；此外接口还保留了早已废弃的时区参数，很容易误导开发者出现错误调用。它的所有功能都可以被更灵活、精度更高的clock_gettime()完全覆盖，因此被标记为过时。
• time()因为本身定位是轻量秒级时间获取接口，在对应的使用场景下没有任何性能或功能缺陷，且有C标准的背书，因此没有被弃用。

简单总结：被弃用的API都是存在功能局限性、设计缺陷，且已有更完善替代方案的接口；而time()作为通用基础接口，覆盖场景广、无明显缺陷，因此一直被保留。

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