On 2020-06-02 23:32, Adriano dos Santos Fernandes wrote:
On 02/06/2020 16:45, Mark Rotteveel wrote:
Documentation should be improved for this case too.
This essentially means that
select * from atable where sometimecolumn > current_time;
will yield different results when the time zone is 'Europe/Amsterdam'
than it does when the time zone is UTC. I think that is extremely
confusing, and not acceptable.
Test case showing the problem (with time/tz constant), please.
For constants we can explain this away with the fact that 'it is the
time on 2020-01-01', that logic doesn't really work well with something
that is purported to be the current time, and is defined as based on
UTC.
I'm specifically talking about the fact that given TIME WITH TIME ZONE
is defined as time in UTC with additional information (either offset or
a named zone) to derive a local time, that CURRENT_TIME in fact does not
conform to that definition, because it is in fact not UTC. Right now in
Europe/Amsterdam it is 13:37 (11:37 UTC). If I use CURRENT_TIME right
now, I will get a time of 12:37 UTC (which is intended to render as
13:37), which is not correct. Especially not if you consider the fact
that the mere changing of the time zone using SET TIME ZONE 'UTC' would
result in a time of 11:37 UTC.
In essence, I think this makes named zones largely meaningless for TIME
WITH TIME ZONE. If we can't fix this somehow, then I at least want an
option (DPB-item/SET xxx) where even with a named session time zone,
CURRENT_TIME and CURRENT_TIMESTAMP and casts of literals to TIME WITH
TIME ZONE will yield offset-based times (derived from the named zone
rules for 'right now'). Otherwise I see no other option than to make
Jaybird default to use UTC or the offset at connect time as the session
time zone for sake of correctness.
Mark
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
