rhn-support-jolee not sure without looking more deeply, the commit is from more than 2 years ago.

Submitted the PR to upstream and added the patch files to local build.

Working off your patch (but on master to isolate the changes), I created https://github.com/rareddy/olingo-odata4/pull/2

This should consistently handling the differentiation between local date/time types and the instant datetimeoffset value. We'll consider java.util.Date and all subclasses and Long as not having timezone information.

We'll also properly normalize the sql date/time values.

rhn-engineering-shawkins another go about it https://github.com/rareddy/olingo-odata4/commit/5884900866b93b6ac4e3e7fb3c982b7be97b005e let me know what you think?

JRE8 is not an option, they wanted to peg at 1.6 compatibility model for other product related issues. Yes, I will give a shot to default TZ.

If not, then the only thing that makes sense to me would be to interpret everything in the system/default timezone (removing the inconsistent usage of GMT).

Could they bring in Joda time (or JRE 8)? Using LocalTime and LocalDate as the canonical mapping would clarify that the values are not instants / intended to carry time zone information.

Unfortunately there is no such agreement to keep the values in/out in GMT in OData specification, it just that these values do not have any TZ info at all. Treating them strings or some special construct in Java would have been straight forward, since they are ties to java.sql.Time and java.sql.Date it is making difficult. The right (talking it loosely, I am lost what is right..) thing to do is, define another property such as "defaultTimeZoneForEdmDate" and have a default to "GMT". That way it can be configurable, and decision is in the hands of the developer. For unit tests I can lock it with GMT. WDYT?

If there is agreement that Edm.Date and Edm.TimeOfDay should default to GMT in/out, then a property isn't needed unless you are trying to maintain backwards compatibility. I was thinking when I first looked at the patch that your flag on EdmDateTimeOffset changed the actual value, but it just selects between equivalent string forms for the same instant. A flag for Edm.Date and Edm.TimeOfDay would actually change the values.

rhn-engineering-shawkins On second thought you are correct, I should have treated the Edm.Date and Edm.TimeOfDay similarly for converting to string. I will post another update in little while.

> EdmDateTimeOffset has Timezone information, but tests are written such that they expected "GMT"

Yes, that make sense. With a different default timezone the string forms would be different, but the values would be functionally the same. So you are just forcing it into GMT.

EdmDateTimeOffset has Timezone information, but tests are written such that they expected "GMT", but there were series of conversions between default time zone and GMT to make all work. So, I simply removed the GMT for EdmdatTimeOffset and let the TZ set on the object take precedence. For unit tests I introduced system property, to convert back to GMT.

Where as Edm.Date and Edm.TimeOfDay do not have TZ info, so coming in I assumed they are "GMT", while going out converted the time to GMT and then sent it out. So, I thought the flag is not required here.

Is there a reason for the system property with EdmDateTimeOffset and not the other types?

You could also simplify things in EdmDateTimeOffset:

Calendar dateTimeValue = null;
    
    // normalize to GMT for output
if (Boolean.getBoolean("normalizeEdmDateTimeOffsetToGMT")) {
    dateTimeValue = createDateTimeInGMT(value);    
} else {
    dateTimeValue = createDateTime(value);
}

And move createDateInGMT method to EdmDateTimeOffset as createDateTimeInGMT.

You can also avoid creating the additional Calendar in createDateTimeInGMT in the Calendar case, but that's a very minor concern.

rhn-engineering-shawkins can you take look at this patch, if think this is good, then I will submit to Olingo folks. https://github.com/rareddy/olingo-odata4/commit/d1938c0a92cb3cbba1a31f8b5f985b7e599fbfa0

This issue sending round n round again with Olingo. There are lots of tests failing. They wrote for consumption the GMT is assumed, but on production side there the timezone set on the Time/Date/Timestamp is assumed. In cases of Edm.Date and Edm.TimeOfDay, I am going to convert them to GMT based time object then output the string form of it.

Added https://issues.apache.org/jira/browse/OLINGO-864

These are comments from OData TC not Olingo folks. So, we need to generate respective JIRA in Olingo JIRA.

> No, they are saying the parsing Date or Time should be exactly same in every time zone

Their own code seems to contradict that, as the assume GMT for parsing.

To highlight the issue:

TimeZone.setDefault(TimeZone.getTimeZone("GMT+1"));
Date date = EdmTimeOfDay.getInstance().valueOfString("11:11:11", true, 4000, 0, 0, true, Date.class);
assertEquals("Thu Jan 01 12:11:11 GMT+01:00 1970", date.toString());
String val = EdmTimeOfDay.getInstance().valueToString(date, true, 4000, 0, 0, true);
assertEquals("11:11:11", val);

The last line will fail because the output will be 12:11:11 instead - which means that the string parse->Java->string cycle is inconsistent when the default timezone is not GMT.

This may just be a misunderstanding of Java Date/Time - see EdmDateTimeOffset.createDateTime the case with value instanceOf Date uses Calendar.getInstance(), but has some comment about UTC - which is not meaningful and should not be different than the java.sql.Time handling. They should be using Calendar.getInstance("GMT"). The Calendar case has a similar issue.

EdmTimeOfDay and EdmDate only work correctly when represented by either java.sql.Time or Long. So this shouldn't affect us in the TimeOfDay case as the runtime type will be java.sql.Time. However it will be an issue with EdmDate that we either have to workaround by converting our runtime values to longs or get them to fix this.

No, they are saying the parsing Date or Time should be exactly same in every time zone

Meaning GMT correct?

The OData TC folks said take it as "literal" with no timezone information, for both EdmDate and EdmTimeOfDay