我在xquery中玩了一些dateTime函数，我注意到xquery接受时区有-14小时的日期。
查看维基百科link我可以看到允许的最小时区为-12H，但xpath functions似乎允许-14H。我错过了什么吗？
答案 0 :(得分：6)
虽然+/- 12h（换句话说：一天）足以跨越整个世界，但有理由进一步偏离。一个很好的例子是汤加和萨摩亚+ 13h，实际上以西 Howland和贝克岛有-12h。这是有道理的：Howland和Baker岛与美国相连（在西岸有-8h），而汤加和萨摩亚与澳大利亚和新西兰的贸易更为重要。基里巴斯和Line Islands的默认值为+ 14h。
时区不时变化。特别是在日期边界附近，国家决定与另一个国家进行贸易和合作，而另一方面则是＃34;日期区域更重要，并调整自己的时区，以便于沟通。 Samoa actually changed their timezone just recently
考虑到政治变化，允许+/- 14h提供一些灵活性，而无需更改规范。然而，+ 14h似乎有点武断;让我们希望法属波利尼西亚（或任何其他与欧洲关系比欧洲更密切的小岛屿不要考虑将时区改为+ 15h。
答案 1 :(得分：2)
它来自ISO，两个方向都达到14。虽然目前没有区域将时间定义为-14，但有些区域将其定义为+14（汤加），而Etc / GMT-14则为-14：00偏移。
答案 2 :(得分：2)
有趣的问题。 XSD 1.0在one place
中说所有时间星期均为协调世界时（UTC，有时称为“格林威治标准时间”）。在将文字转换为值的过程中，词汇表示中指示的其他时区将转换为UTC。 “当地”或未定时时间被假定为适当法律机构规定的某些未指明地点的时区;目前没有合法规定的时区，其持续时间大于14小时。
在another中，它说：
根据目前使用的时区，[值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：00：00说这发生在10东部[标准]时间？或10中部[白昼]时间？是在东部时间上午10点之前或之后标记时间14：30：00.0Z ？在一般情况下，唯一可能的答案是“是的，可能”。）
与闰秒一样，时区偏移也是如此：拥有一个接受所有合法值的数据类型，拒绝所有虚假值，并且在计算和组织上易于处理，这将是一件好事。由于我们似乎无法定义这样的类型，因此我们可以进行最好的近似，并继续前进。 （为什么在一个案例中的解决方案允许看似虚假的值，如没有管辖权实际使用的偏移量，而在另一种情况下，禁止实际上合法的值，例如那些落在闰秒内的值？问题。我能提供的唯一答案是：工作组做出了可以管理的最佳近似值，并且......最终......继续前进。）