Grails 5.3 Date Binding Time Zone Configuration Change and Its Impact on Persisted Dates

Goal

Determine a consistent date‑binding strategy for a Grails application that serves users across multiple regions while preserving the intent of user‑entered dates and avoiding unexpected shifts after persistence.

Constraints and uncertainties

• The grails.databinding.dateTimeZone property (introduced in Grails 5.3) controls how incoming date strings are parsed, but it does not store time‑zone metadata with the persisted java.util.Date.
• GORM saves the raw Date value, so displaying it later using the JVM’s default zone can produce a different wall‑clock time.
• Upgrading to Grails 6 removes this property in favor of JSR‑310 types, creating a compatibility boundary that may require changes to forms, APIs and tests.
• There is no built‑in mechanism to retain the original time zone of a user input, forcing developers to consider custom converters or separate storage fields.

Given these factors, what approach should be taken to balance data integrity, upgrade effort and user experience?

Should grails.databinding.dateTimeZone be set to UTC globally to normalize stored timestamps?

How can original time‑zone information be preserved without framework‑level support?

What migration steps are required when moving from Grails 5.x to Grails 6 where the dateTimeZone property is removed?