xsd的语义：dateTime没有时区，并将其转换为Date [英] Semantics of the xsd:dateTime without timezone and its conversion to Date

问题描述

我有一个关于XML Schema的内置类型 xsd：dateTime 的问题。

没有时区的 xsd：dateTime 的语义？例如 1970-01-01T00：00：00 。

我已经阅读了许多XML Schema规范文件但是找不到应该如何处理。

具体来说，我想了解如何转换 xsd：dateTime 到日期（如 java.util.Date 或JavaScript Date ）对象正确。

旁注：我非常了解Java util类，如 DatatypeConverter 或 DatatypeFactory 我想找到定义如何进行此转换的XML Schema规范。

Date 类（在Java中以及JavaScript中）是这些类具有时区（默认为本地时区）。如果我在输入时没有时区获取一个 xsd：dateTime ，那么我必须以某种方式去决定我应该承担哪个时区。否则我只是不能将其转换为时区（例如 Date ）。

现在的问题是，我应该怎么做我在下面看到以下选项：

• 假设某些默认值为UTC。


• 假设本地时区处理器。

我不太喜欢第二个选项。这是完全随机的！在我的机器上，如果我运行

  System.out.println（DATATYPE_FACTORY 
 .newXMLGregorianCalendar（1970-01- 01T00：00：00）
 .toGregorianCalendar（）。getTime（）。getTime（））; 
  

我将获得-3600000，0，3600000 GMT + 1，GMT或GMT-1还有更多的变体，这取决于夏天的时间，这是非常随意的，我真的没有得到这个，这是否比我们有一个像

pre> < date-time> 1970-01-01T00：00：00< / date-time>


我们实际上不知道这个时间是什么意思？

第一个选项（假设UTC）对我来说似乎更有效但是这显然不是什么（至少）Java工具正在做的。

所以可以请某人给我一个指向某种规范的指针，定义无时间的 xsd：dateTime ？

谢谢。

strong>更新：

目前的调查结果是：

• 未指定时区具有未指定时区的语义，即不能盲目地假定UTC或本地处理器的时区或任何。这是一些本地时区，但哪一个 - 你不知道。


• 这基本上意味着严格来说，你不能转换 xsd：dateTime 到具有特定时区的Date对象 - 除非是关于缺席时区的假设。


• 作为一个工具提供者，我不能真正做到这种知情的假设。我没有数据或其语义的背景。


• 这使我得出结论，工具用户必须明确地或隐含地提供这样的假设。

我的解决方案如下：

• 在我的库中我有一个所谓的上下文对象，它提供XML流程上下文（JAXB JAXBContext 的模拟）。我将使用诸如 getDefaultTimezoneOffset（）和 setDefaultTimezoneOffset（int timezoneOffset）
$ b的方法扩展此对象$ b
• 默认情况下，此方法将返回一些默认值。我现在更喜欢 0 （UTC）。然而，可以是本地时区（如Java工具）。


• 欢迎库用户提供不同的默认时区偏移量，但不是严格要求（隐含假设在这里）


• 解析 xsd：dateTime 到 Date 缺少一个时区，它将被假定为 context.getDefaultTimezoneOffset（）。


• 我还会注意到时间解析的Date对象中的区域（或缺少）。例如在像 originalTimezoneOffset 这样的属性中。这不会修改 Date 对象的值，但会提供一些附加的上下文信息（例如，当该值再次打印时）。


• 当打印 Date 时，库将检查 originalTimezoneOffset ，如果提供了它，则在渲染时考虑

解决方案

基本上，时区是缺少信息，有很多方法解释缺席信息;最终取决于你。可能的解释是：

• 时区是未知的




• 时区可以从上下文建立，例如相关联的地方




• 时区为UTC

XPath / XQuery / XSLT系列规范假定上下文定义的时区。这里的上下文可能是用户的区域设置，或软件运行的机器的时区，或任何数量的其他功能。

从某种意义上说，没有别的时间省略，只给一个日期。当你说你1973年3月21日出生时你的意思是什么？你在说什么时区？假设您可能已经遗漏了这些信息，因为没有人可能会关心。

I have a question concerning XML Schema's built-in type xsd:dateTime.

What are the exact semantics of xsd:dateTime without a timezone? Ex. 1970-01-01T00:00:00.

I've read through a number of XML Schema spec documents but could not find out how should it be processed.

Specifically, I want to understand how to convert xsd:dateTime to the Date (like java.util.Date or JavaScript Date) object correctly.

Side note: I am perfectly aware of Java util classes like DatatypeConverter or DatatypeFactory, I would like to find the XML Schema spec that defines how to do this conversion.

The problem with the Date class (in Java as well in JavaScript) is that these classes do have timezones (defaulted to the local time zone). If I'm getting a xsd:dateTime without time zone on input then I have to deside somehow, which time zone I should assume. Otherwise I just can't convert it to a timezoned value (like Date).

Now the question is, what should I assume. I see following options here:

• Assume something default like UTC.
• Assume local timezone of the processor.

I don't really like the second option. It is entirely random! On my machine, if I run

System.out.println(DATATYPE_FACTORY
    .newXMLGregorianCalendar("1970-01-01T00:00:00")
    .toGregorianCalendar().getTime().getTime());

I'll get -3600000, 0, 3600000 for GMT+1, GMT or GMT-1 (and even more variants depending on summer time. This is so arbitrary, I'm really not getting this. Does this mean than when we have an XML document with an element like

<date-time>1970-01-01T00:00:00</date-time>

we have actually no idea, which exactly time instant was meant?

The first option (assuming UTC) seems more valid to me but this is apparently not what (at least) Java tools are doing.

So could please someone give me a pointer to a spec of some kind defining semantics of the timezoneless xsd:dateTime?

Thank you.

Update:

Current findings are:

• Unspecified time zone has exactly the semantics of the "unspecified" time zone, that is, you can't blindly assume UTC or local time zone of the processor or whatever. This is some local time zone, but which one - you don't really know.
• This basically means that strictly speaking you can't convert xsd:dateTime to Date object which has a specific time zone - UNLESS an assumption about the absent time zone is somehow made.
• As a tool provider, I can't really make an informed assumption of that kind. I have no background on data or its semantics.
• This leads me to the conclusion that the tool user has to provide such assumption - either explicitly or implicitly.

My solution will be as follows:

• In my library I have a so-called context object which provides the XML procession context (analog of JAXB JAXBContext). I will extend this object with a methods like getDefaultTimezoneOffset() and setDefaultTimezoneOffset(int timezoneOffset)
• By default, this method will return some default value. I prefer 0 (UTC) at the moment. However can be local time zone (like Java tools do) as well.
• Library user is welcome to provide a different default time zone offset, but it is not strictly required ("implicit" assumption here)
• When parsing xsd:dateTime to Date, if incoming value is missing a time zone, it will be assumed to be the context.getDefaultTimezoneOffset().
• I will also note the incoming time zone (or lack thereof) in the parsed Date object. For instance in a property like originalTimezoneOffset or something like that. This will not modify the value of the Date object but will provide some additional context information (for instance when the value should be printed again).
• When printing a Date, the library would check for the originalTimezoneOffset and if it is provided consider it when rendering the lexical value.

解决方案

Basically the timezone is absent information, and there are many ways of interpreting absent information; in the end it's up to you. Possible interpretations are:

• the timezone is unknown

• the timezone can be established from the context, e.g. an associated place

• the timezone is UTC

The XPath/XQuery/XSLT family of specifications assume a context-defined timezone. The context here could be the locale of the user, or the timezone of the machine on which the software is running, or any number of other things.

In a sense it's no different from omitting the time and giving only a date. What exactly do you mean when you say you were born on 21 March 1973? What timezone are you talking about? The assumption is probably that you've left out the information because no-one is likely to care.

这篇关于xsd的语义：dateTime没有时区，并将其转换为Date的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！