我很好奇在任何给定语言中处理模棱两可的日期字符串的最佳方法是什么。如果无法预先验证您的用户输入,应该如何解析 MM/dd/YYYY 日期?
您将如何解析以下模棱两可的日期以及出于什么原因(统计、文化等)?
'1111900'是 1900 年 1 月 11 日 [ M/dd/YYYY ] 还是 1900 年 11 月 1 日 [ MM/d/YYYY ]?
我很好奇在任何给定语言中处理模棱两可的日期字符串的最佳方法是什么。如果无法预先验证您的用户输入,应该如何解析 MM/dd/YYYY 日期?
您将如何解析以下模棱两可的日期以及出于什么原因(统计、文化等)?
'1111900'是 1900 年 1 月 11 日 [ M/dd/YYYY ] 还是 1900 年 11 月 1 日 [ MM/d/YYYY ]?
除非您确切知道该格式来自什么语言/文化,否则您需要建立一个通用的日期格式。
我会推荐一种称为区域设置中性日期格式的东西。(YYYY-MM-DD)
它要么使用它,要么清楚地知道年、月和日是什么部分。(DD MON YYYY 或 2003 年 4 月 22 日)
请参阅:w3对日期格式的看法。
编辑:输入错误的区域中性日期格式
根据软件的重要性,我会将任何不明确的日期输入视为无效输入。您应该确保(在源头上)您获得的日期输入采用合理、明确的格式。如果您仍然设法得到“1111900”之类的内容,那么输入不正确,显然有人以某种方式绕过了有效性检查代码,您可以做的最正确的事情可能是丢弃数据。
当然,如果这不是一个选项并且获得日期位置并不重要,您总是可以猜测 - 但这将是一个猜测。如果可能的话,我肯定会避免这种情况。一般来说,接受未经处理的输入并不是最好的主意。
在这样的系统中,了解 1 月 11 日和 11 月 1 日之间差异的唯一方法是通过上下文。否则,您需要进行某种消歧。这种特定的日期格式将是病态破坏性压缩的完美示例。
当重要的日期是使用报价下拉菜单或日历时,我的偏好是它总是以预期的格式出现。