Stream: hapi
Topic: Date and Time weirdness
Keith Boone (Jan 05 2020 at 05:16):
Working with the Java data types, I'm noticing quite a bit of unexpected behavior when manipulating dates.
- copy() doesn't behave as expected with respect to string value.
- Making any changes to the date value reverts the string representation to the system default time zone.
- Data arithmetic using calendar units doesn't appear to be behaving as expected.
This is all with the HAPI 4.0.1 data types, but I know some of these bugs have been around for a bit.
Grahame Grieve (Jan 05 2020 at 12:34):
@James Agnew
James Agnew (Jan 05 2020 at 17:01):
@Keith Boone these sound like bugs but i'm not sure i understand any of them exactly.. are you able to provide test cases?
Keith Boone (Jan 06 2020 at 17:34):
Yes, they are bugs, and yes I can provide test case, and will file them.
In first case, load a date as string using a TZ different from your local default. Change the precision, or set it exact same time from Date value , or use add function to change the value. Note a different value.
In next case, make a copy of the date using copy() method. Print string values of original and copy. They should be equal but are not.
James Agnew (Jan 06 2020 at 19:53):
Ah yeah, that one is known... Comes down to the use of a java Date object as the underlying data structure. We picked that back when we were still supporting Java 6.
We really ought to replace that Date with a javax.time.Instant now that we're on Java 8. That's a painful change though...
Last updated: Apr 12 2022 at 19:14 UTC
