The falling back to system default zoneId behaviour is good for dates and times which do not have a zone. However, in the instance of ZonedDateTime, they DO have a zone, and it would be helpful if it retained that zoneId (unless overridden in the tag)
The current mechanism means that servlet code that manipulates the zone of a ZonedDateTime (E.G withZoneSameInstant), has the zone changes discarded when rendered.
In my application, all dates are stored in the database in UTC, and as part of the DAO layer, converted to a configurable timezone. The tag not obeying this timezone means that the times displayed are wrong.
For now, as the configurable timezone is global throughout the UI of the application, I have added a zoneid tag to my template, but this feels like a bit of a hack.
The falling back to system default zoneId behaviour is good for dates and times which do not have a zone. However, in the instance of ZonedDateTime, they DO have a zone, and it would be helpful if it retained that zoneId (unless overridden in the tag)
The current mechanism means that servlet code that manipulates the zone of a ZonedDateTime (E.G withZoneSameInstant), has the zone changes discarded when rendered.
In my application, all dates are stored in the database in UTC, and as part of the DAO layer, converted to a configurable timezone. The tag not obeying this timezone means that the times displayed are wrong. For now, as the configurable timezone is global throughout the UI of the application, I have added a zoneid tag to my template, but this feels like a bit of a hack.