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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
