You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firebird 4 just before beta 2 changed how it derived the base UTC time for a named zone, by always using 2020-01-01. To make sure values in Jaybird are consistent, it must also use 2020-01-01 when deriving the value of a java.time.OffsetTime. Do be aware that this means the derived offset value is as it applies at 2020-01-01, so for example '20:58:00 Europe/Amsterdam' will be '20:58:00+01:00', even if the value is derived on a date during summertime. Especially when using CURRENT_TIME, this may yield confusing results.
description: Firebird 4 just before beta 2 changed how it derived the base UTC time for a named zone, by always using 2020-01-01. To make sure values in Jaybird are consistent, it must also use 2020-01-01 when deriving the value of a java.time.OffsetTime. Do be aware that this means the derived offset value is as it applies at 2020-01-01, so for example '20:58:00 Europe/Amsterdam' will be '20:58:00+01:00', even if the value is derived during summertime.
Firebird 4 just before beta 2 changed how it derived the base UTC time for a named zone, by always using 2020-01-01. To make sure values in Jaybird are consistent, it must also use 2020-01-01 when deriving the value of a java.time.OffsetTime. Do be aware that this means the derived offset value is as it applies at 2020-01-01, so for example '20:58:00 Europe/Amsterdam' will be '20:58:00+01:00', even if the value is derived on a date during summertime. Especially when using CURRENT_TIME, this may yield confusing results.
Submitted by: @mrotteveel
Jira_subtask_inward JDBC622
Firebird 4 just before beta 2 changed how it derived the base UTC time for a named zone, by always using 2020-01-01. To make sure values in Jaybird are consistent, it must also use 2020-01-01 when deriving the value of a java.time.OffsetTime. Do be aware that this means the derived offset value is as it applies at 2020-01-01, so for example '20:58:00 Europe/Amsterdam' will be '20:58:00+01:00', even if the value is derived on a date during summertime. Especially when using CURRENT_TIME, this may yield confusing results.
See also jdp-2020-06 OffsetTime derivation for named zone (https://github.com/FirebirdSQL/jaybird/blob/master/devdoc/jdp/jdp-2020-06-offsettime-derivation-for-named-zone.md)
Commits: 3b0a97b
The text was updated successfully, but these errors were encountered: