On 06.04.2020 12:10, Mark Rotteveel wrote:
On 2020-04-05 21:49, Adriano dos Santos Fernandes wrote:
On 05/04/2020 12:40, Mark Rotteveel wrote:
If we do decide to follow the standard in this regard, then I would
recommend that we make an exception for the conversion applied by the
bind of TIME ZONE (or a specific time zone type) to LEGACY to convert
using the session time zone.
SET BIND just changes automatic described types.
Types used by client messages (which generally but not always comes from
the described types) works likes standard variables.
So no, that would be a complete hack. And yes, this may be problematic
for bind of TZ to WITHOUT-TZ types, although there are the extended
types which makes this less worse.
The extended types are not a solution for clients that need to use a
legacy binding to function correctly. With legacy bind, clients that
don't support the new types clientside can still work with the data.
If we are effectively going to truncate time zone information, that
means that clients with legacy bind will get inconsistent (and, in my
opinion, unusable) information when accessing a database that has
times in different zones or offsets (because 2020-04-06 01:00:00+02:00
and 2020-04-06 01:00:00+04:00 would both be transformed to 2020-04-06
01:00:00, making the values meaningless). The current conversion
from/to the session time zone at least allows a coherent view of the
data (effectively normalized to a single zone), with a session zone of
Europe/Amsterdam the previous times would be transformed to 2020-04-06
01:00:00 and 2020-04-05 23:00:00, which makes sense.
I 100% agree with Adriano that making rules for server/client transfers
differ from the rest places is bad-bad-bad. Luckily looks like we have
no voices suggesting to follow standard exactly in this aspect i.e. all
problem with having an exception for SET BIND appears meaningless.
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
