WeasyPrint生成PDF在macOS Preview中显示UTC时间的分析与解决

问题现象分析

在使用WeasyPrint 64.1生成PDF文件并在macOS Preview 11.0中打开时，用户发现创建日期显示为UTC时间而非本地时间。相比之下，使用Wkhtmltopdf生成的PDF文件则能正确显示本地时间。

通过对比两种工具生成的PDF文件，发现WeasyPrint生成的日期格式为(D:YYYYMMDDHHmmSSOHH'mm)，而Wkhtmltopdf生成的格式为(D:YYYYMMDDHHmmSSOHH'mm')，后者多了一个末尾的单引号。

技术背景

PDF规范中关于日期时间的格式定义经历了演变过程：

1. PDF 1.4规范中，日期格式示例包含末尾的单引号
2. PDF 1.7规范中，存在排版错误，导致部分示例显示末尾有单引号
3. PDF 2.0规范中，这个错误被修正，明确日期格式应为(D:YYYYMMDDHHmmSSOHH'mm)

问题根源

macOS Preview在处理PDF日期时存在特殊行为：

1. 对于符合PDF 2.0规范的日期格式（无末尾单引号），Preview会将其解析为UTC时间
2. 对于不符合规范的格式（有末尾单引号），Preview会忽略时区信息，默认使用本地时间

这种处理方式导致：

• WeasyPrint生成的合规PDF在Preview中显示UTC时间
• Wkhtmltopdf生成的不合规PDF反而显示本地时间

解决方案建议

1. 对于用户：

   • 使用--pdf-variant=pdf/a-3b参数生成PDF/A文件，这类文件使用不同的日期格式
   • 向Apple反馈此问题，促使Preview改进日期解析逻辑

2. 对于开发者：

   • WeasyPrint应保持生成合规的PDF日期格式
   • 其他PDF生成工具应修正日期格式中的多余单引号

技术启示

1. 规范遵循与兼容性的平衡：即使遵循最新规范，也可能因阅读器实现差异导致显示问题
2. 日期时间处理的重要性：跨平台、跨工具的日期时间显示一致性是常见挑战
3. 向后兼容的考量：工具开发者需要考虑不同版本规范间的兼容性问题

这个案例展示了标准规范演进过程中可能遇到的实现差异问题，提醒开发者在处理日期时间等敏感信息时需要特别谨慎。