On 2020-03-05 11:48, Alex Peshkoff via Firebird-devel wrote:
On 2020-03-04 20:35, Mark Rotteveel wrote:
On 04-03-2020 18:16, Alex Peshkoff via Firebird-devel wrote:
No. Use of them is very restricted - the _ONLY_ place where they can
be used in SQL is SET BIND statement.
I had missed that, but why not just always put those two bytes in the
WITH TIME ZONE data?
Yes, we thought about such way. Main reason not to go that way for me
was that Adriano was strongly against that and I did not want to
continue that discussion.
And yet, here we are, discussing this.
Other reasons is that this "extended" slution is sooner of all
temporal. ICU becomes a natural part of all OSes (for posix that
already hapepned a few years ago, new windows also contains ICU). I.e.
long term everything will work just fine by default with std type. But
we need something working today (hard to imagine a noise @sql.ru when
people noticed that they receive GMT-time using fb4), therefore such
temporal extension.
But due to it's temporal nature always adding 2 more bytes may really
appear wrong, is not it?
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.
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. The v13+ protocol writes a
null bitvector instead and doesn't write a null indicator, so it doesn't
fit after the WITH TIME ZONE data, which means it is padded anyway.
But I forgot that in the wire protocol, the 2 bytes with the zone
information is actually written out as 4 bytes, so the padding isn't
actually relevant, and this would then be more of discussion if we
encode the information in a way that yields 4 bytes extra in the wire
protocol, or would share the same 4 bytes in the wire protocol. The
'original' time zone types are 8/12 bytes, and the 'extended' time zone
type is now 12/16 bytes in the wire protocol, while given the actual
data size, both could be 8/12 bytes.
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.
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.
In short, I don't see why this should be a separate type. Unifying it in
a single type reduces complexity(*), which makes things simpler.
*: Though having 2x 2 bytes (or 2x 4 bytes in the current wire protocol)
with an offset is a bit confusing, but that also applies to the current
EXTENDED time zone types.
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?
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
