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?
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
}
}),
How do you solve these problems?
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",
})
}
})
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)
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).
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)
If I use
new sap.m.DatePicker({
value : {
path : "Date",
type : new sap.ui.model.type.Date({
style: "short",
UTC: true
})
}
})
Data seems to be correct (the 2 hours are not missing after picking a new date).
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?
Strange enough I have a similar problem by using a filter. But there the UTC flag seems not working.
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 :-/
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.
I can't answer with regard to SAP, as I am not familiar. But I can provide some insights based on OData.
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.
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
From ISO 8601 3rd Edition §4.3.2:
The zone designator is empty if use is made of local time ...
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.
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.
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.
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.
Hope that helps.