Mark, I hope you never release a Jaybird version that converts named regions to offsets in Java, because if you do you misunderstood the thing completely and Jaybird users will need to have a very wrong behavior forever.
Adriano Em qui, 5 de mar de 2020 11:50, Mark Rotteveel <m...@lawinegevaar.nl> escreveu: > 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 >
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
