Re: [Firebird-devel] Time zones

[Mark R. <ma...@la...>]

On 30-4-2018 04:50, Adriano dos Santos Fernandes wrote:
> Time zones branch is almost feature complete.
> 
> There is two important subjects left:
> 
> - ICU in Windows - as I already said, it need to be upgraded and I would
> like it builded as the upstream does, i.e., with full data. It would be
> good if someone volunter to do it as I do not have nor even known what
> compiler version should be used.
> 
> - Compatibility:
> 
> It was been created four new datatypes:
> - TIME WITH TIME ZONE
> - TIMESTAMP WITH TIME ZONE
> - TIME WITHOUT TIME ZONE
> - TIMESTAMP WITHOUT TIME ZONE
> 
> The old types (TIME and TIMESTAMP) resolves to the "WITHOUT" version.
> 
> So the first compatibility problem is when client selects the types WITH
> TIME ZONE.
> 
> It can be resolved with same solution as DECFLOAT (SET DECFLOAT BIND ...):
> - SET TIME ZONE BIND { NATIVE | LEGACY } (better suggestion welcome)

Could you please define this compatibility problem that `SET TIME ZONE 
BIND { NATIVE | LEGACY }` is meant to solve and in what way it solves 
it? That way it becomes a lot easier to suggest alternative wording.

> Also there are new expressions, LOCALTIME and LOCALTIMESTAMP with
> functionality equivalent to the Firebird's CURRENT_TIME and
> CURRENT_TIMESTAMP.
> 
> But standard CURRENT_TIME and CURRENT_TIMESTAMP  works different than
> Firebird, as they returns the "WITH TIME ZONE" types.
> 
> Tweaking CURRENT_TIME/CURRENT_TIMESTAMP for compatibility is problematic.
> 
> It may be in stored routines or in ad-hoc queries. Stored routines are
> sometimes "recompiled" by tools, i.e., recreated from sources.
> 
> If there is attachment option that changes the behavior of DDL commands,
> users will soon have problems when sometime it will be used and sometime
> it will not.
> 
> Also database config option for this will create problems as each client
> (submitting queries) will work different.
> 
> So what I propose here is a migration path that does not breaks the new
> feature nor the old code if users implement the migration correct.
> 
> I propose to add LOCALTIME/LOCALTIMESTAMP to next Firebird 3 version as
> synonym for its CURRENT_TIME/CURRENT_TIMESTAMP.
> 
> So before migrate to v4, users can adjust their code using Firebird 3
> and once upgraded there will be no problems.

Sounds like a great plan, but I don't that will happen (as in, I don't 
think a lot of people will do that). It might be better to add another 
session property that handles this (or tie it to the previous one as 
well), optionally with a global (and per database) configuration option 
in firebird.conf and databases.conf.

Also, I assume that CURRENT_TIME and CURRENT_TIMESTAMP will continue to 
work correctly when directly assigning to a TIME/TIMESTAMP (WITHOUT TIME 
ZONE) field/column. Is that assumption correct?

-- 
Mark Rotteveel