* Fix usage of Calendar in tests
The tests use Calendar instances. For some test cases the time zone of a
Calendar instance is changed and then passed to the valueToString
method.
Unfortunately after just changing the time zone the Calendar only
changes the time zone but not the value of the calculated fields like
YEAR, MONTH, ... . These fields are recalculated only if they are read
by get(YEAR), get(MONTH), ... . The implementation of valueToString
clones the Calendar instance before fields are computed resulting in
a corrupt clone.
This change
1) makes sure that the test the fields in the Calendar instances used
in the tests are computed
2) makes sure that the valueToString method triggers a computation of
the fields before cloning the Calendar
* Support types of new Date/Time API
The types of the new Date/Time API can now be used as property values.
The following mappings are now supported
EdmDateTimeOffset
- java.time.Instant
- java.time.ZonedDateTime
- java.util.Calendar
- java.util.Date
- java.sql.Timestamp
- java.lang.Long
EdmDate
- java.time.LocalDate
- java.sql.Date
EdmTimeOfDay
- java.time.LocalTime
- java.sql.Time
Only these mappings capture the semantics correctly.
For legacy reasons also supported are the following mappings are still
supported:
EdmDate
- java.util.Calendar (date component in the TZ of the calendar)
- java.util.Date (date component in UTC)
- java.sql.Timestamp (date component in UTC)
- java.lang.Long (date component in UTC)
EdmTimeOfDay
- java.util.Calendar (time component in the TZ of the calendar)
- java.util.Date (time component in UTC)
- java.sql.Timestamp (time component in UTC)
- java.lang.Long (time component in UTC)
For legacy reasons the default mapping types are unchanged (and remain
semantically incorrect):
EdmDateTimeOffset -> java.sql.Timestamp
EdmDate -> java.util.Calendar
EdmTimeOfDay -> java.util.Calendar
* Allow additional (but semantically wrong) conversions
EdmDate -> java.util.Date, java.sql.Timestamp
EdmTimeOfDay -> java.util.Date, java.sql.Timestamp
