On 2020-03-05 17:49, Mark Rotteveel wrote:
I see general benefits of communicating the actual offset always, see
also below. And I don't think it is a good idea to add a new datatype
which can have meaningful uses, only to remove it again at a later
time. That will surely break applications or libraries that would rely
on that datatype. Right now (bit of hyperbole), it sounds like this
solution was only written to solve the display problem in ISQL, and
considering this as a temporary solution, is too much as if Firebird
and its wire protocol are only consumed by ISQL.
Could it be only isql - nobody will care about that too much. That is
fblient-level problem, i.e. any client working with time zone datatypes
has same problem. I've talked about 'ISQL' just as a sample of client.
And if I want to use some other (like fresh flamerobin) I get:
Preparing statement: select current_timestamp from RDB$DATABASE
Error: *** IBPP::LogicException ***
Context: RowImpl::AllocVariables
Message: Found an unknown sqltype !
Why introduce an extra datatype, when you could also do it always
for this new data type (the WITH TIME ZONE types have 2 bytes of
padding anyway).
That's also not completely true. If you use gpre - yes, that's
correct. But in SQL message format each field is always followed by
NULL indicator which is exactly 2 bytes and ideally fits after WITH
TIME ZONE data.
From a wire protocol perspective, the NULL indicator is written
separately from the data, after the padded buffer of the datatype, and
that is only in the v12 and earlier protocol.
Ahh - yes, sorry, I was talking about message format.
I see a general benefit of always including the offset (or including
the offset for named zones). For example, drivers or users who don't
want to (or cannot) implement named zone support can correctly read
values with named zones with the actual offset. I can think of quite a
bit of code in Jaybird I can throw away by using those last 2 bytes
for the offset and relying on Firebird to determine the offset. I
could set the bind on connect, but having the BIND configurable after
connect means that a user can change it, which would require the
driver to either support named zones, or just fallback to UTC. And if
this datatype is intended as a temporary, transitional, measure, then
it means that I can't rely on it, as it means it is essentially
without value to invest time to support it.
Well, nobody is going to throw it away, I\ve just supposed that it will
be not so much in use.
To be honest, if the main argument for this is the display problem in
ISQL, then I think we can just as well do without this type, and the
users of ISQL should just learn to live with the fallback behaviour to
render in GMT (or UTC) if ICU is not available.
Somewhy people do not want to do it. Moreover that's not isql-only problem.
In short, I don't see why this should be a separate type.
I've tried to explain...
That's a pity that not successfully.
For example, it isn't entirely clear to me yet how those last two
bytes are handled in client-to-server communication, do they need to
be set to a meaningful value or for example set to 0xFFFF, or will
those bytes just be ignored?
Ignored.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
