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).
So only conversion to string seems to be a real problem. And IMHO we could live with that.
Session-level option comes to mind, but this new feature will require one new session-level option anyway (client TZ) and I'd rather avoid having one more option just to please time->string conversions.
Dmitry ------------------------------------------------------------------------------ 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
