On 04-03-2020 18: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 think this is extremely confusing, making both SQL
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? 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).
and the wire protocol more convoluted.
Did not notice it when adding datatype :-) Certainly one more type means
a bit efforts in XDR but that's not more than a few lines of code.
To me, this commit[1] looks like a lot more than just a few lines of
code, and supporting the type in Jaybird could also add some more
headaches for me. Having two ways to do something is always more work
than having one way to do something.
PS.
PR @github existed for >2 weeks. Why did you not ask questions that time?
Because I don't monitor pull requests on the Firebird GitHub, I just saw
it when looking at recent commits on master.
PPS.
If determining time zone offset by code is not a problem for Java client
I suppose there is no big need in supporting extended format at all in it.
Jaybird will always use offsets, but it can read the zone ids as well,
whether or not it can convert them depends on whether or the zone name
is known (they should all be known iirc from implementing this).
Using the offset as determined by Firebird however could simplify things
as I could do away with the code related to zone lookups.
[1]:
https://github.com/FirebirdSQL/firebird/commit/2d2df601a39772da721e8b4fea80ffef584ea8f2
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
