Safari与Chrome解析Datetime字符串存在差异，求原因及最优方案

嘿，这个跨浏览器的日期解析差异问题确实挺坑的，我来给你拆解一下原因和解决方案：

问题根源 #

你遇到的是不同浏览器对不带时区信息的ISO 8601日期字符串的解析行为不一致：

• Chrome（以及现代Firefox等浏览器）会把"2018-03-30T00:00:00"这类不带时区标识的ISO字符串，默认当成本地时间来解析，所以显示的是你所在时区（PDT，UTC-7）的3月30日0点。
• 而旧版本的Safari（以及部分其他旧浏览器）会将这类无时区的ISO字符串视为UTC时间，所以把UTC的3月30日0点转换为PDT时区时，就变成了3月29日17点（UTC-7小时）。

最优解决方案 #

要彻底解决跨浏览器的一致性问题，有两个可靠的方向：

1. 明确指定时区（推荐） #

如果你的业务逻辑中这个日期是UTC时间，直接在字符串末尾加上Z标识（代表UTC）：

var d = new Date("2018-03-30T00:00:00Z");
document.getElementById("demo").innerHTML = d;

这样所有浏览器都会统一解析为UTC时间，再转换为本地时区显示，结果完全一致。

如果这个日期本身就是本地时间，那更稳妥的方式是手动构造Date对象，不依赖ISO字符串的自动解析：

// 注意：月份是从0开始计数的（3月对应2）
var d = new Date(2018, 2, 30, 0, 0, 0);
document.getElementById("demo").innerHTML = d;

这种方式完全规避了浏览器解析差异，所有环境下都会创建你期望的本地时间。

2. 手动解析ISO字符串（适合必须用ISO格式的场景） #

如果一定要用ISO格式的字符串输入，可以手动拆分日期组件，再用Date.UTC()或者直接构造本地时间：

var isoStr = "2018-03-30T00:00:00";
var [year, month, day, hour, minute, second] = isoStr.split(/[-T:]/);
// 构造UTC时间
var d = new Date(Date.UTC(year, month - 1, day, hour, minute, second));
// 或者构造本地时间：
// var d = new Date(year, month - 1, day, hour, minute, second);
document.getElementById("demo").innerHTML = d;

总结 #

最省心的方案要么是给ISO字符串加上明确的时区标识，要么直接手动构造Date对象，彻底避开浏览器之间的解析行为差异。

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