Python中不使用时间函数查找最大EPOCH时间戳的方法及验证

给出的示例代码存在两处可修正的问题：

• 基础语法错误：for each in range(0, len(times): 行缺少闭合右括号，补全后手动遍历比较最大值的核心逻辑是可以正常跑出正确结果的，但工程实现上有明显缺陷：
  • 没有空列表边界处理：如果传入的times是空集合，直接给latest_time赋值times[0]会触发索引越界异常
  • 实现冗余：手动遍历比较列表最大值属于重复造轮子，代码可读性和运行效率都不如内置方法

• 直接调用Python内置的max()方法即可完成最大值查找，对应代码为latest_time = max(times)，该方法原生支持可迭代对象的遍历比较，代码简洁且经过长期验证，运行效率远高于手动写循环的实现
• 对比过程不需要做额外类型转换：只要参与比较的都是合法EPOCH数值，不管是整数（秒级精度）还是浮点数（毫秒/微秒级精度），都可以直接用大小运算符做比较，不需要转成字符串或者时间对象再比对

这个结论不是无条件成立的，需要分场景判断：

• 在所有待比较EPOCH时间戳都是基于同一UTC时钟基准、没有人为篡改、格式统一的前提下，结论完全成立：Unix EPOCH的定义就是从1970-01-01 00:00:00 UTC开始累计的秒数，数值越大代表累计的时间间隔越长，对应的实际时刻越靠后
• 出现以下任意一种情况时，数值大小和实际时间的对应关系就会失效，不能直接认为最大值对应最新时间：
  • 不同来源的时间戳存在时钟偏差：比如采集自不同设备的时间戳，某台设备因为NTP校准失败时钟快了1小时，它生成的更大数值的时间戳，实际代表的时刻可能比另一台校准准确的设备生成的较小数值的时间戳更早
  • 系统时钟发生过回溯调整：如果设备通过NTP校时把之前快了的时钟往前拨回了正确时间，就会出现新生成的EPOCH数值比之前记录的旧数值更小的情况
  • 时间戳格式不统一：如果列表里混入了非Unix纪元的整数时间戳（比如Windows文件时间、Excel从1900年开始计数的日期序列值），哪怕都是整数，数值大小对应的实际时间也会完全错位
  • 时区处理错误：如果把本地时间直接当成UTC时间转成EPOCH值存入列表，比如东八区的本地时间2024-01-01 00:00被错误转成了EPOCH值，这个数值会比同真实UTC时刻的标准EPOCH小28800，和正常的UTC EPOCH混在一起比较就会出现大小错位

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