On 2017-11-21 16:56, Dmitry Yemanov wrote:
21.11.2017 17:55, Adriano dos Santos Fernandes wrote:
Implementing TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE
datatypes
as specified in the SQL standard is not a big problem.
However, standard says that CURRENT_TIME / CURRENT_TIMESTAMP returns
the
timed-zone datatype.
That causes two problems:
- Internally (say in PSQL), conversion to string would return
different
result than now
- Externally, tools will take time to support this datatype
Externally, all the apps use SQL_TIME/SQL_TIMESTAMP and I expect TZ
values to be implicitly casted (coerced) to non-TZ data types when
dealing with existing apps. Surely, proper support of TZ values will
require time/efforts, but at least nothing will be broken (even if
CURRENT_TIME/TIMESTAMP are used).
How, I would assume that in 'select current_timestamp from
rdb$database', that this would lead to something like type
SQL_TIMESTAMP_TZ in the new situation, so no coercion applies here,
unless there is a session level config (or something) that would force
SQL_TIMESTAMP here.
Mark
------------------------------------------------------------------------------
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