UTC时区下gmtime()函数在闰秒时是否会返回tm_sec=60？

这个问题问到点上了——闰秒对C标准库时间函数的影响其实挺依赖具体实现的，不是所有系统都会返回tm_sec=60的情况。咱们一步步拆开来聊：

1. C标准的核心定义 #

C标准（包括C99、C11及后续版本）并没有强制要求时间函数处理闰秒。也就是说，标准里的gmtime()并没有规定必须支持表示秒数为60的情况，绝大多数主流实现都是基于“平秒”（即每天固定86400秒）来设计的。

2. Unix时间戳（time_t）的本质 #

通常time_t是从1970-01-01 00:00:00 UTC开始累计的秒数，但这个计数是忽略闰秒的：当闰秒插入时，Unix时间戳不会增加到86401，而是要么重复最后一秒（比如把23:59:59再计数一次），要么直接跳过，始终保持每天86400秒的计数规则。

3. 针对你提到的time_t=915148800的具体情况 #

这个值对应的是非闰秒场景下的1999-01-01 00:00:00 UTC。而1998年的闰秒是在1998-12-31 23:59:60 UTC插入的，这个“实际闰秒时间”并没有对应的唯一time_t值——因为Unix时间戳不记录闰秒。所以：

• 如果你的服务器是普通主流配置（比如默认的Linux、macOS），系统根本不识别闰秒的存在，gmtime(915148800)只会返回1999-01-01T00:00:00，不管是不是处于闰秒时段。
• 如果你的系统是少数支持闰秒的特殊配置（比如启用了闰秒支持的Linux内核、专业计时系统），情况会更复杂：有些实现会把闰秒映射到前一个time_t值（即915148799），此时gmtime()可能返回1998-12-31T23:59:60；但time_t=915148800依然对应1999-01-01T00:00:00，不会因为闰秒时段而改变。

4. 关于tm_sec=60的可能性 #

只有当系统的时间库明确支持闰秒表示时，gmtime()才会返回tm_sec=60。比如部分遵循POSIX.1-2008扩展的系统，或者加载了包含闰秒数据的tzdata且启用了相关支持的系统，才可能出现这种情况。但要注意，这种场景非常少见，而且很多编程语言和系统库为了避免逻辑混乱，会自动将60秒转换为下一分钟的0秒。

总结 #

绝大多数普通服务器环境下，你不用指望gmtime()返回tm_sec=60。如果你的业务需要精确处理闰秒，建议使用专门的高精度计时API，或者手动结合闰秒数据进行处理。

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