您的位置: 首页  >  技术问答  >  如何在SAPUI5中正确处理Edm：DateTime表单OData接口？

如何在SAPUI5中正确处理Edm：DateTime表单OData接口？

分类: 技术问答 • 2022-05-01 20:14:16
问题描述：

是否有定义应在SAP Netweaver Gateway服务的OData Edm：DateTime中发送什么值？
特别是应该始终将其解释为UTC吗？

Is there a definition what values should be send in OData Edm:DateTime of a SAP Netweaver Gateway service? Especially should it always be interpreted as UTC?

我假设如果接口定义正确，SAPUI5库足够聪明，可以自动处理所有这些时区问题-问题是，什么是正确的？

I assume the SAPUI5 library is smart enough to handle all this time zone problems automatically if the interface is correct defined -- question is, what is correct?

我希望在客户端使用这样的代码：

I would prefer to use some code like this, at client side:

new sap.m.DatePicker({
     value : {
         path : "BirthDate",
         type : new sap.ui.model.type.Date
     }
}),

如何解决这些问题？

时区处理对我来说仍然很奇怪。
SAP Gateway Server发送以下时间的Edm：DateTime：2015-04-16T00：00：00
缺少任何时区信息。

Time zone handling seems still to be strange to me. SAP Gateway Server sends in an Edm:DateTime following: 2015-04-16T00:00:00 Any time zone information is missing.

如果我这样绑定日期选择器：

If I bind a date picker like this:

var oContent = new sap.m.DatePicker({
    value : {
        path : "Date",
        type : new sap.ui.model.type.Date({
                    style: "short",
                })
    }
})

我得到以下输出：16.04.15（似乎是正确的） 。
绑定不带类型信息的日期选择器会显示：2015年4月16日，星期四，格林尼治标准时间+0200（MitteleuropäischeSommerzeit）

I got the following output: 16.04.15 (seems to be correct). Binding a date picker without type information shows: Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)

如果我用日期选择器到2015年4月17日的第二行是：
2015年4月17日星期五00:00:00 GMT + 0200（MitteleuropäischeSommerzeit）
请注意时间上的差异（缺少2小时）。

If I change the date with the date picker to 17.04.15 the second line is: Fri Apr 17 2015 00:00:00 GMT+0200 (Mitteleuropäische Sommerzeit) Please note the difference in time (2 hours missing).

如果我将其发送到服务器，则会得到Edm.DateTime == 2015-04-16T00：00：00
控制显示：
4月16日星期四2015 02:00:00 GMT + 0200（MitteleuropäischeSommerzeit）

If I send it to the server I got Edm.DateTime == 2015-04-16T00:00:00 Control shows: Thu Apr 16 2015 02:00:00 GMT+0200 (Mitteleuropäische Sommerzeit)

如果我使用

new sap.m.DatePicker({
value : {
    path : "Date",
    type : new sap.ui.model.type.Date({
                style: "short",
                UTC: true
        })
}
})

数据似乎是正确的（选择一个新日期后2小时没有丢失）。

Data seems to be correct (the 2 hours are not missing after picking a new date).

我问我，有什么定义将发送哪种类型的数据网关？
如果Edm.DateTime信息中缺少时区，客户端应如何正确工作？

I am asking me, is there any definition what type of data gateway will send? If the timezone is missing inside the Edm.DateTime information how should a client work correct? Especially if clients are in different time zones available?

奇怪的是，如果使用不同的时区的客户，我有一个类似的问题，使用过滤器。但是，那里的UTC标志似乎不起作用。

Strange enough I have a similar problem by using a filter. But there the UTC flag seems not working.

任何对此主题有经验的人吗？或有关好的文档的任何提示？
* https://sapui5.netweaver.ondemand.com /sdk/#docs/guide/91f3070d6f4d1014b6dd926db0e91070.html
说或多或少的保重，但不是这样：-/

Anyone with some experience on that topic? Or any hints to a good documentation? * https://sapui5.netweaver.ondemand.com/sdk/#docs/guide/91f3070d6f4d1014b6dd926db0e91070.html Says more or less "take care" but not how :-/

我在SAP网络上检测到相同的问题（ http ：//scn.sap.com/thread/3574419 ）。不知道给定的答案是否正确。看起来好像不需要在元数据中乱窜吗？

I detected the same question on SAP network (http://scn.sap.com/thread/3574419). Not sure if the given answer is correct. Looks like hacking around in meta-data which should not be required?

我仍在寻找解决该问题的方法

I am still searching for a solution to this problem

在绑定和过滤器使用的情况下，我检测到不同的数据处理方式。

I detected different handling of data in case of binding and filter usage.

答

我无法回答不熟悉SAP。但是我可以提供一些基于OData的见解。

I can't answer with regard to SAP, as I am not familiar. But I can provide some insights based on OData.

Edm：DateTime 类型基于 W3C XML模式 xs：dateTime ，这又基于 ISO8601 。 XML Schema和ISO8601都声明没有时区的时间都被视为本地时间。也就是说，某人本地。

The Edm:DateTime type is based on the W3C XML Schema xs:dateTime, which is in-turn based on ISO8601. Both XML Schema and ISO8601 state that times without a time zone are to be considered "local time". That is, local to someone. Whose "local" it is intentionally undefined.

从W3C XML模式§3.2.7：

From W3C XML Schema §3.2.7:


本地或无时区的时间假定为相应法律机构规定的某些未指定地区的时区中的时间。

"Local" or untimezoned times are presumed to be the time in the timezone of some unspecified locality as prescribed by the appropriate legal authority

根据ISO 8601第3版§4.3.2：

From ISO 8601 3rd Edition §4.3.2:


如果使用当地时间，则区域标记为空。 。

The zone designator is empty if use is made of local time ...

请考虑您的示例 2015-04-16T00：00：00 。知道这是什么时间的确切时间的唯一方法是应用一些其他上下文。在生日的情况下，这可能是该人当前所在的时区（他们庆祝生日的地方，而不是他们出生的地方）。或者，如果该人的位置未知，则可能是任意位置-也许是使用该系统的人的时区。

Consider your example of 2015-04-16T00:00:00. The only way to know what exact moment in time this refers to is to have some additional context applied. In the case of a birthday, this could be the time zone where the person is currently located (where they celebrate their birthday, not where they are born). Or, it could be some arbitrary location if the person's location is unknown - perhaps the time zone of the person using the system.

因此，解释值的em>是应用时区的位置。在您的情况下，似乎在反序列化过程中会应用某些本地时区。

Therefore, the interpretation of the value is where the time zone is being applied. In your case, it would appear that some local time zone is being applied during deserialization.

还请注意，生日最好用日历日期而不是午夜来表示约会 Edm：Date 类型更适合于此。对于其他类型，尤其是如果您知道该值是UTC或特定时区，则 Edm：DateTimeOffset 更合适。

Also consider that a birthday is better represented by just a calendar date, rather than midnight on a date. The Edm:Date type is better suited for this. For other types, especially if you know that the value is UTC or in a specific time zone, then Edm:DateTimeOffset is more appropriate.

还认识到 Edm：DateTime 类型已从4.0版本的OData规范中删除。许多人（包括我自己）都认为这是一个错误。我不确定这是否会影响您，但您应该知道。

Also recognize that the Edm:DateTime type was dropped from OData spec in version 4.0. Many (including myself) consider this a mistake. I'm not sure if this affects you or not, but you should be aware.

希望有帮助。

相关推荐