为什么当涉及到小数时,ISO-8601规范似乎被普遍忽略? [英] Why does the ISO-8601 specification appear to be universally ignored when it comes to decimals?

查看:176
本文介绍了为什么当涉及到小数时,ISO-8601规范似乎被普遍忽略?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

从ISO-8601:2004(E)规范:

From the ISO-8601:2004(E) Specification:


4.2.2.4具有小数部分的表示

如果特定应用程序需要,可能会包含小时,分钟或秒的小数点数
。如果包含小数部分,则省略低阶时间
元素(如果有的话),小数部分为
,以整数部分除以ISO
31- 0,即逗号[,]或全停止[。]。其中,逗号是
的首选标志。

If necessary for a particular application a decimal fraction of hour, minute or second may be included. If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign.

足够简单。所以根据这个规范,比较好的是使用分隔整数和小数部分的逗号来写一秒钟,例如 2014-01-01T00:00:00,123 。然而,似乎到处都是,只有一个小数点(也称为全停)被接受!

Simple enough. So according to this spec, fractions of a second are preferred to be written using a comma separating the whole and decimal parts, such as 2014-01-01T00:00:00,123. However it seems that just about everywhere, only a decimal point (aka "full stop") is accepted!

现在我确定有一些语言或库这是考虑到的,我知道在许多情况下,您可以自己提供格式的完整详细信息。但是,对于这个规范来说,这样的监督看起来似乎是各种各样的程序员犯了同样的错误。

Now I'm sure there are some languages or libraries that took this into account, and I know in many cases you can supply the full details of the format yourself. But it seems like such a glaring oversight of the specification and it appears that a wide variety of programmers have made the same mistake. Is there a reason why this is the case, other than pure human error?

以下是我测试过的列表。如有任何其他问题,请随时编辑问题以增加我的清单。谢谢。

Below is a list of where I tested. Feel free to edit the question to augment my list if you find any others. Thanks.

DateTime dt = DateTime.Parse("2014-01-01T00:00:00,123");

使用消息String抛出一个 FormatException 未被识别为有效的DateTime。

Throws a FormatException with the message "String was not recognized as a valid DateTime". The same thing with a period instead of a comma parses successfully.

最新测试(在这篇文章中)Chrome,Internet Explorer,Firefox和Node.js:

Tested in latest (as of this writing) Chrome, Internet Explorer, Firefox and Node.js:

var dt = new Date('2014-01-01T00:00:00,123');

返回无效日期

var valid = moment("2014-01-01T00:00:00,123").isValid();

返回 false 。使用期限代替返回 true

Returns false. Using a period instead returns true.

echo strtotime('2014-01-01T00:00:00,123');

返回一个空字符串。

require 'time'
puts Time.iso8601("2014-01-01T00:00:00,123")

提供运行时错误。虽然时间不会保持分数秒,但不应该出错 - 确实如果使用了一段时间,它可以工作。

Gives a runtime error. While Time doesn't keep fractional seconds, it shouldn't error - and indeed if a period is used instead, it works.

推荐答案

纯ISO-8601兼容解析器必须支持逗号和点。逗号不是严格要求的,只能推荐使用。所以关于这个标准,JavaScript,PHP,Ruby等的例子清楚地表明这些解析器实现的错误。

A pure ISO-8601-compliant parser MUST support both comma and dot. The comma is not strictly required, only recommended. So regarding this standard the given examples of JavaScript, PHP, Ruby etc. clearly indicate an error of those parser implementations.

RFC3339确实只支持一个子集(不包括逗号AND也不包括小时或小数分钟!) - 所以不完全符合ISO标准。

RFC3339 indeed only supports a subset (excluding the comma AND also excluding decimal hours or decimal minutes!) - so not fully ISO-compliant.

XML模式类似。不幸的是,它不包括逗号(参见W3C文档)。

XML-schema is similar. It excludes the comma, unfortunately (see the W3C-document).

所以你问为什么?这是我的怀疑:编程世界被美国强占主导。在美国文化中,点用作小数分隔符。因此,大多数人开发这样的框架,标准和图书馆都坐在美国,错误地认为点是准国际标准。

So you ask why? That is my suspicion: Programming world is strongly dominated by US. In US culture the dot is used as decimal separator in numbers. So most people developing such frameworks, standards and libraries are sitting in US and mistakenly think that dots are quasi an international standard.

所以问题是,为什么ISO使用/推荐逗号?我不知道它,但我们都知道ISO集团的办公室位于巴黎,而不在美国。而在欧洲(不包括英国),逗号通常是小数分隔符,也是文化方面。

So the question remains, why ISO uses/recommends the comma? I don't know it exactly, but we all know the office of ISO group is located in Paris, not in US. And in Europe (excluding UK) the comma is generally preferred as decimal separator, also a cultural aspect.

最后,并不是所有的解析器都是错误的。至少 Joda-Time 也支持逗号,虽然喜欢打印中的点。 NodaTime的情况如何?我希望至少与Joda-Time类似。请继续支持解析逗号。从欧洲的角度来看,很高兴看到并不是所有的东西看起来都像美国人; - )。

Finally, not all parsers are wrong. At least Joda-Time supports comma, too, although preferring the dot in printing. What is the situation in NodaTime? I hope at least similar to Joda-Time. Please keep supporting parsing of comma. From an european perspective it is nice to see that not all stuff looks like american ;-).

这篇关于为什么当涉及到小数时,ISO-8601规范似乎被普遍忽略?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆