Stream: hapi
Topic: Bug in BaseDateTimeType
Grahame Grieve (Aug 31 2020 at 23:19):
hey @James Agnew there's a pretty serious bug just cropped up in BaseDateTimeType.
Consider this code:
String src = "2015-08-25T02:11:36";
DateTimeType dt = new DateTimeType(src);
Assertions.assertEquals(dt.primitiveValue(), src);
DateTimeType dt2 = new DateTimeType(dt.getValue());
Assertions.assertEquals(dt2.primitiveValue(), src);
The second assertion fails:
org.opentest4j.AssertionFailedError: expected: <2015-08-25T02:11:36+10:00> but was: <2015-08-25T02:11:36>
Grahame Grieve (Aug 31 2020 at 23:20):
This is in R5, but I expect it's the same in all versions
James Agnew (Sep 01 2020 at 14:51):
Huh, interesting.
I think at one point we errored out if a datetime with time but not TZ was provided, but that was softened at some point and that led to what we have here (a TZ being inferred, which I agree is awful).
Should we just preserve the (technically invalid) string there? (as opposed to throwing an error?)
Grahame Grieve (Sep 01 2020 at 20:37):
I talked to James about this. It's inherent in the fact that BaseDateTimeType is a PrimitiveType<Date>. This was done originally for Java 6 compatibility and is no longer required. In fact, it's a liability. So we're considering changing the parameter type more recent that supports timezones. This is obviously a big change but Date is definitely liability.
Does anyone have any opinion about this?
Jens Villadsen (Sep 01 2020 at 20:52):
Change the type - thats my two cents
Karl M. Davis (Sep 02 2020 at 02:12):
Grahame Grieve said:
I talked to James about this. It's inherent in the fact that BaseDateTimeType is a PrimitiveType<Date>. This was done originally for Java 6 compatibility and is no longer required. In fact, it's a liability. So we're considering changing the parameter type more recent that supports timezones. This is obviously a big change but Date is definitely liability.
Does anyone have any opinion about this?
I don't think the change would break backwards compatibility in the serialized JSON or XML, right? If not, FWIW, my default opinion is that any code using Date is wrong/broken.
Grahame Grieve (Sep 02 2020 at 02:14):
right. It doesn't change anything about how the type works except where you use .getValue() / .setValue()
Grahame Grieve (Sep 02 2020 at 02:14):
but I've had to fix a few bugs in the last couple of days associated with this usage
Last updated: Apr 12 2022 at 19:14 UTC
