上周上线了一个新功能，第二天收到全球用户反馈：时间显示全错了。
美国用户显示昨天，欧洲用户显示明天，亚洲用户有的对有的错。
排查了一整天，最后发现是一个简单的日期格式问题。
问题现象
功能是在线预约系统，用户选择时间后，服务器保存，再显示给用户。
测试环境没问题，上线后部分用户反馈时间不对。
排查过程
第一步：怀疑时区
服务器是UTC时间，用户本地有时区转换。但代码里已经做了时区处理，不应该有问题。
第二步：怀疑前端显示
前端用了 toLocaleString() ，但不同浏览器表现不一致。Chrome和Firefox差8小时，Safari正常。
第三步：发现真正原因
不是时区问题，是日期格式解析问题。
用户输入的是 2025-04-21 10:00 ，后端用 SimpleDateFormat 解析：
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm");
Date date = sdf.parse(userInput);
问题出在用户输入格式不统一：
有的用户输入 2025/04/21 10:00 （斜杠）
有的输入 21-04-2025 10:00 （日月年）
有的输入 2025-04-21 （没有时分）
SimpleDateFormat 解析失败时，不会报错，而是静默解析成错误时间。
解决方案
改用 DateTimeFormatter ，严格匹配格式，解析失败直接报错：
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm");
LocalDateTime dateTime = LocalDateTime.parse(userInput, formatter);
或者更灵活，支持多种格式：
public LocalDateTime parseDate(String input) {
String[] patterns = {
"yyyy-MM-dd HH:mm",
"yyyy/MM/dd HH:mm",
"dd-MM-yyyy HH:mm"
};
for (String pattern : patterns) {try {return LocalDateTime.parse(input, DateTimeFormatter.ofPattern(pattern));} catch (DateTimeParseException e) {// 继续尝试下一个格式}
}
throw new IllegalArgumentException("无法解析日期: " + input);
}
前端统一
前端用 ，强制格式 yyyy-MM-ddTHH:mm ，减少用户输入错误。
教训
1.
不要信任用户输入，即使看起来格式正确
2.
解析失败要报错，不要静默处理
3.
前后端格式统一，避免转换错误
4.
全球化测试，至少测3个时区
数据影响
这次bug影响了约15%的全球用户，主要是手动输入时间的用户。自动填充的用户没问题。
修复后加了输入校验和格式提示，类似问题没再出现。