我在xquery中玩了一些dateTime函数，我注意到xquery接受时区为-14小时的日期。
查看维基百科链接，我可以看到允许的最小时区是 -12H，但 xpath 函数似乎允许 -14H。 我错过了什么吗？
世界各地的时区
虽然+/-12h(换句话说：一天(足以跨越整个世界，但有理由进一步偏离。一个很好的例子是汤加和萨摩亚+13h，实际上是豪兰以西和贝克岛有-12h。这是有道理的：豪兰岛和贝克岛隶属于美国(西岸有-8小时(，而汤加和萨摩亚与澳大利亚和新西兰的贸易更为重要。基里巴斯和莱恩群岛甚至默认有+14h。
时区更改
时区会不时变化。特别是在日期边界附近，碰巧各州决定与日期区"另一边"的另一个国家的贸易与合作更为重要，并调整自己的时区以便于沟通。 萨摩亚实际上最近才改变了他们的时区。
允许 +/-14h 提供了一定的灵活性，考虑到政治变化，而无需更改规范。 不过，+14h 似乎有点武断; 让我们希望法属波利尼西亚(或任何其他与欧洲关系比美国更密切的小岛(不要考虑将其时区更改为+15h。
它来自ISO，它在两个方向上都达到14。虽然目前没有区域将其时间定义为-14，但有些区域将其定义为+14(汤加(，而Etc/GMT-14是-14：00偏移量。
有趣的问题。 XSD 1.0 在一个地方说
所有时区时间均为协调世界时(UTC，有时称为"格林威治标准时间"(。在将文字转换为值期间，词法表示形式中指示的其他时区将转换为 UTC。"本地"或未时区时间推定为有关法律当局规定的某个未指定地点的时区中的时间;目前没有法律规定的时区，即持续时间大于14小时。
在另一个中，它说：
根据当前使用的时区，[值 2000-01-20T12：00：00Z] 可能从 2000-01-20T12：00：00+12：00 到 2000-01-20T12：00：00-13：00。但是，根据当地法律，该范围将来可能会扩大或缩小。因此，以下定义使用范围更广的不确定值：+14：00..-14：00。
这向我表明，Jens Erat的建议(允许偏移量比当前已知需要的任何偏移量大一点，以防万一(很好地达到了目标。 我没有查阅XSD工作组在相关时期的讨论清单，看看是否提出了其他论点。
至于某些司法管辖区或其他司法管辖区转移到+15：00偏移的可能性，JE是对的，这可能有点尴尬。 这个问题在 XSD 1.0 中似乎不那么重要，因为在 1.0 中，时区偏移量只是一种词汇现象，与值无关(始终是 UTC(;在 1.1(以及 XPath 2.0 和相关规范(中似乎更重要，时区偏移量是值的一部分。
但是，这种抵消转移的一大动机似乎是(当时，至少对工作组中的一些人来说(是希望成为第二个千年将首先到来的世界的一部分，随之而来的是额外的旅游收入。至少，这种动机暂时已经消失了。
无论如何，即使时区偏移量是值的一部分，它与当地民用时间的关系也几乎从来都不是简单的。 许多司法管辖区以不可预测的方式将当地民用时间的偏移量更改为UTC(而不仅仅是为了寻求旅游收入(。 任何想要将时间值与当地民事时间相关联的人都必须使用裸time值以外的其他东西，无论是否带有偏移量。 (10：00：00.00-05：00 说这发生在东部时间 10 点还是中部时间 [夏令时间]？ 标记为东部时间上午 10 点的时间是在 14：30：00.0Z 之前还是之后？ 在一般情况下，唯一可能的答案是"是的，可能"。
与闰秒一样，时区偏移量也是如此：最好有一个接受所有合法值、拒绝所有虚假值并且在计算和组织上易于处理的数据类型。 由于我们似乎无法定义这样的类型，因此我们进行了我们可以管理的最佳近似值，然后继续前进。 (为什么在一种情况下，解决方案允许看似虚假的值，例如没有司法管辖区实际使用的偏移量，而在另一种情况下，不允许实际上合法的值，例如闰秒内的值？问得好。 我能提供的唯一答案是：工作组做出了它可以管理的最佳近似值，并且......最终。。。继续前进。