FB4 Beta 2 may still be using the current date for TIME WITH TIME ZONE and extended wire protocol. [CORE6328] #6569
Submitted by: Tony Whyman (twhyman)
For testing, I have first set up a simple script i.e.
Create Database 'localhost:/tmp/test.fdb' USER 'SYSDBA' PASSWORD 'masterkey';
Insert into FB4TestData_TZ(RowID,TimeCol) Values(1,'11:31:05.0001 America/New_York');
Run using isql, this gives the expected output i.e. '11:31:05.0001 America/New_York'
I then investigated the same using the development version of the IBX Firebird Pascal API, focusing on decoding the value of the "TimeCol" column when the extended wire protocol is in use.
The Pascal code for decoding the buffer element looks like:
procedure DecodeTimeTZEx(bufptr: PByte;
When I run it through on the debugger, I can see that the buffer is correctly decoded by UtilIntf.decodeTimeTzEx (Hr = 11, etc). However, "dstOffset" is set to -240 and not -300 which would be
If I add to the code:
in order to directly decode the time component in GMT, this is also as expected (i.e. Hr = 16, etc.) So, how did decodeTimeTzEx correctly decode the buffer to the correct local time when the offset provided by the server was out by -60?
I then kill the server and change the system date to '2020/1/1' (at the time the test was first run the system date is 2020/6/9 i.e. when daylight savings time is in effect in America/New_York).
I now see that the buffer is also correctly decoded by UtilIntf.decodeTimeTzEx (Hr = 11, etc). However, the dstOffset is also now correctly set to -300. i.e. the dstOffset appears to be following daylight savings time rules for the current date and not for a fixed date of 2020/1/1.
The only explanation I have is that both server and client were working with the current date and that additionally the client side is ignoring the offset provided in the extended wire protocol.
The text was updated successfully, but these errors were encountered:
Commented by: Tony Whyman (twhyman)
I have updated the query to
Select TIMECOL,Extract(TIMEZONE_HOUR FROM TIMECOL) AS TZ_HOUR,
It came back with a TZ_HOUR = -4 and a TZ_MINUTE = 0
for a time with time zone set as '11:31:05.0001 America/New_York'
and a query run on 2020.7.14