30.04.2018 5:50, Adriano dos Santos Fernandes wrote:
Hi!
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.
"Official" compiler for fb3 on Windows is (old) VC10. Snapshot builds of
both fb3 and fb4 uses VC12, iirc. So far there is no decision what we will
use as "official" compiler for fb4.
- 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.
I suppose you speak about old clients here, which have no support for
new datatypes, correct ?
It can be resolved with same solution as DECFLOAT (SET DECFLOAT BIND ...):
- SET TIME ZONE BIND { NATIVE | LEGACY } (better suggestion welcome)
What should be used by default ? How conversion "TIME WITH TIME ZONE"
to "TIME" will happen - will it just ignore time zone information, or
will it change value of time (accouting time zone) returned to the client ?
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.
How it is different from problem above ?
It may be in stored routines or in ad-hoc queries. Stored routines are
sometimes "recompiled" by tools, i.e., recreated from sources.
What if store new datatype at BLR level but return datatype according to
the SET TIME ZONE BIND rule ?
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.
Agree, DPB is not good for such things.
Also database config option for this will create problems as each client
(submitting queries) will work different.
Explain, please. It seems for me that SET TIME ZONE BIND statement with
default values set at database level (via config) could resolve all issues.
Am i wrong ?
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.
I'd add it into 2.5.9 also, as many users will upgrade from per-v3 versions.
BTW, we could (should ?) add more such forward-compatibility features into
last release of 2.5
Regards,
Vlad
------------------------------------------------------------------------------
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
