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
Just before the Firebird 4 beta 2 release, the decision was made to base the UTC derivation for TIME WITH TZ literals with a named zone on 2020-01-01 instead of the current date. This causes off-by-one-hour issues with the logic in Jaybird to use the current-date for determining the offset for the named zone.
As an example, selecting time'13:25:32.1235 Europe/Amsterdam' on the 15th of May will now yield an offset time 14:25:32.123500+02:00 instead of either 13:25:32.123500+02:00 (older snapshots of Firebird 4), or 13:25:32.123500+01:00 (which would be inline with what Firebird derives).
Find a way to address this, or at least add a caution to the documentation.
The text was updated successfully, but these errors were encountered:
Using 2020-01-01 as base date for offset derivation might be the best and most compatible option, however I have also raised a discussion on firebird-devel if we really want this.
Submitted by: @mrotteveel
Jira_subtask_outward JDBC629
Jira_subtask_outward JDBC630
Just before the Firebird 4 beta 2 release, the decision was made to base the UTC derivation for TIME WITH TZ literals with a named zone on 2020-01-01 instead of the current date. This causes off-by-one-hour issues with the logic in Jaybird to use the current-date for determining the offset for the named zone.
As an example, selecting time'13:25:32.1235 Europe/Amsterdam' on the 15th of May will now yield an offset time 14:25:32.123500+02:00 instead of either 13:25:32.123500+02:00 (older snapshots of Firebird 4), or 13:25:32.123500+01:00 (which would be inline with what Firebird derives).
Find a way to address this, or at least add a caution to the documentation.
The text was updated successfully, but these errors were encountered: