On 04/03/2020 17:16, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:01, Mark Rotteveel wrote:
What is the purpose of introducing yet another datatype called
EXTENDED TIME/TIMESTAMP WITH TIME ZONE?
Help users missing ICU on the client work with time zones.
I am still trying to get my head around this new feature. As I
understand it, it exists for support of broken or legacy systems without
an ICU shared library. That is, following a "SET BIND..." the server's
ICU is used instead of the client's.
My reading is that when the server's ICU is used, TIMESTAMP/TIME with
TIME ZONE values are returned as UTC with both the time zone id and the
time zone offset as computed by the server's ICU taking into account any
daylight savings time variations.
I presume that in extended mode, when a TIMESTAMP/TIME with TIME ZONE is
used as a statement parameter, the value is passed to the server as a
local time plus the time zone id and the server's ICU is used to convert
this to UTC before evaluating the query.
From the user's point of view, the result is the same. There's just a
small extra overhead with the wire protocol in terms of packet size, but
the number of packets is the same.
The question then arises as to why this is not the normal way of
working? Using the client's local ICU introduces a maintenance headache.
If it is out-of-step with the server (or other clients) then
inconsistent results may occur when computing daylight savings time offsets.
So why shouldn't I just always call "SET BIND..." as soon as a database
connection is opened, support only the EXTENDED TIME/TIMESTAMP WITH TIME
ZONE, and avoid the risk of ICU's getting out of step?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
