GraalJS与Nashorn在日期解析行为差异的技术解析

在从JDK 11/Nashorn迁移到Java 21/GraalJS的过程中，开发者发现了一个关于日期时间字符串解析的重要行为差异。本文将从技术角度深入分析这一现象的本质、规范依据以及解决方案。

现象描述

当执行以下JavaScript代码时：

new Date("2023-09-28T00:31:25")

在不同引擎中会得到不同结果：

• Nashorn（时区+05:30环境下）：解析为UTC时间并转换为本地时区，输出Thu Sep 28 2023 06:01:25 GMT+0530 (IST)
• GraalJS（相同时区）：直接按本地时区解析，输出Thu Sep 28 2023 00:31:25 GMT+0530 (IST)

技术背景

ECMAScript规范要求

根据ECMAScript标准对ISO 8601格式字符串的解析规则：

1. 不含时区信息的纯日期格式（如"2023-09-28"）应被解释为UTC时间
2. 含时间部分但无时区的格式（如"2023-09-28T00:31:25"）应被解释为本地时间

引擎实现差异

• Nashorn未严格遵循此规范，将所有无时区信息的时间字符串都视为UTC时间
• GraalJS严格遵循规范，区分了纯日期和日期时间格式的不同处理方式

兼容性解决方案

GraalJS团队通过nashorn-compat模式提供了向后兼容方案。在该模式下：

1. 自动检测是否处于兼容模式
2. 对于日期时间字符串，统一采用Nashorn的UTC解析逻辑
3. 保持与旧系统用户脚本的兼容性

技术建议

对于需要进行引擎迁移的项目：

1. 评估影响：检查现有代码是否依赖Nashorn的特殊日期解析行为
2. 迁移策略：
   • 短期：启用nashorn-compat模式保证兼容
   • 长期：逐步改造代码，显式指定时区信息（如添加"Z"后缀表示UTC）
3. 测试验证：特别注意跨时区场景下的日期时间处理逻辑

最佳实践

1. 始终明确时区信息：

// 明确UTC时间
new Date("2023-09-28T00:31:25Z") 
// 明确指定时区
new Date("2023-09-28T00:31:25+05:30")

2. 对于关键业务逻辑，建议使用专门的日期库（如moment.js）替代原生Date对象

3. 在文档中明确记录系统对日期时间的处理规范

通过理解这些技术细节，开发者可以更顺利地进行引擎迁移，并构建更健壮的日期时间处理逻辑。