On 13-02-2021 13:52, Dimitry Sibiryakov wrote:
13.02.2021 13:41, Mark Rotteveel wrote:
However if we're going to change this, we need to ensure that data
type binding to WITHOUT TIME ZONE types will still work correctly
(AFAIK, it currently uses the same code path as a cast), that is:
render in the session time zone.
Unfortunately it has another problem: SET BIND affects only data type
reported to client by info calls. The rest is up to general data type
coercion mechanic which cannot (should not) be different from CAST one.
Then CAST should remain as it is now, and we should introduce a
construct to 'truncate' a WITH TIME ZONE into a WITHOUT TIME ZONE
without changing its wall clock time.
Suggestions:
- TRUNCATE_TIMESTAMP(tz_value) (as I suggested earlier)
- TRUNC(tz_value) (as you suggested)
- tz_value WITHOUT TIME ZONE (as an analogue of `AT ...`)
The only way to settle it that I see is to introduce one more
client-only data type (SQL_LOCAL_TIMESTAMP?) with separate coercion
rules. It would fit to the family of "extended" timestamps.
That wouldn't help, because the idea of datatype binding (with the
exception of EXTENDED) is that it intends to support clients that do not
know about the new datatypes.
Mark
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
