世界上谁使用 DD-YYYY-MM 和 DD-YY-MM 作为标准日期格式模式？
世界上谁使用 DD-YYYY-MM 和 DD-YY-MM 作为标准日期格式模式？
我应该担心他们吗？
Who, in the world, uses DD-YYYY-MM and DD-YY-MM as standard date format patterns?
Should I worry about them?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
快速浏览 wiki 给了我这个页面
http://en.wikipedia.org/wiki/Date_notation_by_country
没有人使用这种格式。我想没必要担心。
A quick look into wiki gave me this page
http://en.wikipedia.org/wiki/Date_notation_by_country
there is no one who uses this kind of format. no need to worry I guess.
这取决于你从什么地方得到约会以及你可以逃脱什么惩罚。
如果这是一个永远不会输入此类日期的用户使用的应用程序，即使他们这样做，您也可以随时返回错误，那么是的，请务必忽略该格式。
另一方面，如果您正在编写应该从某些未知数据源读取日期的代码，并且如果您无法解析日期，这将是一个问题，那么支持该格式可能是一个非常好的主意。
这归结为契约编程与防御性编程的争论。如果您不支持 DD-YY-MM，那么您的应用程序将无法在 3 年内的某个时间提供这种形式的日期。如果这是可以接受的或不值得付出代价，那么请务必忽略它。
It depends on what you are getting the date from and what you are allowed to get away with.
If this is an application that is going to be used by users who would never enter this type of date and even if they do, you can always return an error, then yes, by all means ignore the format.
If, on the other hand, you are writing code that is supposed to read in dates from some unknown data source and it would be a problem if you could not parse a date, then it is probably a very good idea to support the format.
It comes down to the argument of programming by contract vs. defensive programming. If you don't support DD-YY-MM, then your application will not work right that one time in 3 years that something gives it that form of date. If this is acceptable or not worth the cost, than by all means ignore it.
我关于日期解析的一般经验法则是，如果 strtotime 无法处理它，则将其扔掉并让他们输入一个新的。对于您使用的任何语言，这可能会有所不同，但可能有一个库/函数可以为您解析日期时间，因此您不必担心它。无需重新发明轮子。
My general rule-of-thumb regarding date parsing is, if
strtotimecan't handle it, toss it out and make them type a new one. This may be different for whatever language you're using, but there's probably a library/function that parses datetimes for you so you don't have to worry about it. No need to reinvent the wheel.