Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

TimeStorageType.NATIVE/COLUMN for ZonedDateTime only preserves the offset, not the ZoneId

Description

On H2 at least (didn’t test other DBs), when using hibernate.timezone.default_storage = NATIVE or COLUMN, if you persist a ZonedDateTime with a non-offset ZoneId (e.g. ZoneId.of("Africa/Cairo"), upon reloading from the database the ZonedDateTime will actually use an offset (e.g. ZoneOffset.ofHours(3)), which is different and involves a loss of information.

For NATIVE this may be a limitation of the databases and the timestamp with timezone SQL type, in which case that’s an acceptable limitation.

For COLUMN though, Hibernate ORM itself decides what it stores in the column, so that’s more questionable…

Activity

Show:

Yoann RodièreJuly 16, 2024 at 9:54 AM

Yoann RodièreJuly 16, 2024 at 9:53 AM

Honestly I’m not the one who’ll do the work, so I’m not the once to convince.

If you want this behavior to be improved, I’d recommend coming discuss this on the Zulip channel here: https://hibernate.zulipchat.com/#narrow/stream/132096-hibernate-user/topic/.E2.9C.94.20Generate.20ID.20only.20when.20null.20on.206.2E5

However:

  • It’s been debated a lot, so be prepared for disagreement.

  • It’s too late for ORM 6, as 6.6 is in candidate release phase, and the next version will be 7.

  • Know there’s a related change coming in ORM 7 to avoid conversion between java.sql.Date and java.time, which are one of the main reasons for data loss in this area. Not sure it is the cause of your specific problem, but it is related.

Yannick MajorosJuly 16, 2024 at 8:00 AM

still, timezone information is currently lost for ZonedDateTime: if I store a (summer) date in Europe/Brussels, I’ll get back a date with UTC+2, which is consistent ATM (same instant) but not exactly the same (for an appointment next year, it’s quite possible that daylight saving rules change as this is politically challenged). Maintaining compatibility could be done with a new flag in @TimeZoneColumn which would default to the old behavior. It would solve the information loss issue and make sense for TimeZoneStorageType.COLUMN with ZonedDateTime.

Could this issue be reopened?

Yoann RodièreApril 6, 2023 at 7:33 AM

As I understand it, this was discussed by the ORM team who decided not to change this behavior, so it'll stay that way for the foreseeable future. And personally now that it's been released that way in 6.2 I'd rather it doesn't change until 7.0

Rejected

Details

Assignee

Reporter

Affects versions

Priority

Created March 13, 2023 at 4:51 PM
Updated March 25, 2025 at 12:32 PM
Resolved April 6, 2023 at 7:33 AM