R中as.POSIXct解析毫秒时间时出现800转799的偏差问题咨询

两类时间类型的存储逻辑差异 #

• POSIXlt 采用结构化分量存储：解析字符串时会直接将拆出的年、月、日、时、分、秒值存入对应字段，其中的秒分量会直接保留输入的毫秒数值（本例中的39.800），全程不涉及跨时区总秒数的浮点转换计算，因此解析结果和输入值完全一致。
• POSIXct 采用连续秒数存储：本质是记录从1970年UTC纪元开始计算的双精度浮点数形式的总秒数。

版本专属的解析逻辑缺陷 #

在R 4.0.0到4.0.5版本中，as.POSIXct() 直接解析字符串的内部流程存在实现偏差：这个问题是当时R团队调整夏令时偏移计算逻辑时引入的，没有对毫秒级的小数秒值做精度补偿，导致解析得到时间分量后，计算跨时区（本例为CEST夏令时）的UTC总秒数时，会因浮点运算的截断处理，把原本应为39.800秒的数值计算为略小于真实值约1毫秒的浮点值（即39.799999...）。

注：R中%OS格式化语法采用截断取位而非四舍五入逻辑，这个略小于0.8的浮点值截断到3位小数时就会显示为39.799；因为默认打印逻辑只展示1位秒数精度，就会呈现出"39.7 CEST"的显示效果。

非通用浮点精度问题 #

双精度浮点数在16亿秒量级（对应2020年的时间戳）下的最小可分辨步长约为2.4e-7秒，完全足够支撑毫秒级精度的存储需求。本次出现的偏差完全来自两条解析路径的实现差异，并非底层存储能力不足导致的普遍问题。

• 该问题属于R 4.0系列早期版本引入的程序缺陷，并非正常设计行为。官方已在R 4.0.6补丁版本、R 4.1.0及后续版本中完成修复，新版本会统一as.POSIXct()与as.POSIXlt()的字符串解析流程，不会再出现这类毫秒级偏差。
• 旧版本临时规避方式：遇到同版本的解析偏差时，可先将字符串解析为POSIXlt类型，再强制转换为POSIXct类型即可得到准确结果，示例代码：

  a <- as.POSIXct(as.POSIXlt("2020-09-14 00:01:39.800"))
  format(a, "%Y-%m-%d  %H:%M:%OS3")
  # 输出: "2020-09-14 00:01:39.800"
  

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