On 2020-03-06 07:59, Alex Peshkoff via Firebird-devel wrote:
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 !
That is a different problem: FlameRobin uses IBPP, and IBPP doesn't know
about the new time zones types, so this is one you will need to
workaround by using SET BIND OF TIMESTAMP WITH TIME ZONE TO LEGACY, or
using LOCALTIMESTAMP instead of CURRENT_TIMESTAMP (or really fix by
updating IBPP to support all types since Firebird 3, and fix
FlameRobin). The EXTENDED TIMESTAMP WITH TIME ZONE will not solve this
problem, because just like FlameRobin doesn't know about TIMESTAMP WITH
TIME ZONE, it won't know about EXTENDED TIMESTAMP WITH TIME ZONE.
My point however remains, right now this change seems to be primarily
motivated by people complaining about ISQL using GMT* as a fallback, and
the current solution feels a bit ad-hoc and adding a lot of - in my
opinion - unnecessary complexity.
[..]
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.
I understand it isn't ISQL only, but - to me - the solution seems to be
designed as an afterthought to fix the ISQL problem. I'm arguing that a
solution in a single datatype would be better.
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.
But that explanation primarily seems to boil down to that Adriano didn't
like it and that you didn't want to discuss it any further.
In any case, we seem to have a stalemate here, so I guess there is not
much point in continuing to argue. I'll grudgingly implement support in
Jaybird by handling it identical to a normal TIMESTAMP WITH TIME ZONE,
just in case someone configures a bind to EXTENDED TIME(STAMP) WITH TIME
ZONE.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
