13.02.2021 08:13, Mark Rotteveel wrote:
Maybe we need a TRUNCATE_TIME_ZONE function, which for a TIME/TIMESTAMP WITH TIME ZONE
will return a WITHOUT TIME ZONE equivalent with the same wallclock time.
We could borrow general-purpose TRUNC() from Oracle but personally I would prefer
standard C
On 13-02-2021 11:20, Dimitry Sibiryakov wrote:
13.02.2021 08:13, Mark Rotteveel wrote:
Maybe we need a TRUNCATE_TIME_ZONE function, which for a
TIME/TIMESTAMP WITH TIME ZONE will return a WITHOUT TIME ZONE
equivalent with the same wallclock time.
We could borrow general-purpose TRUNC() fro
13.02.2021 12:00, Mark Rotteveel wrote:
Firebird already has a TRUNC.
That's good, no need for another reserved word.
The current behaviour of CAST to me makes more sense than the behaviour defined in the
standard. I can see that there might be cases when you might want the time without tim
On 13-02-2021 12:06, Dimitry Sibiryakov wrote:
13.02.2021 12:00, Mark Rotteveel wrote:
Firebird already has a TRUNC.
That's good, no need for another reserved word.
The current behaviour of CAST to me makes more sense than the
behaviour defined in the standard. I can see that there might
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
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 i
Provide time zone ids constants in public headers
-
Key: CORE-6485
URL: http://tracker.firebirdsql.org/browse/CORE-6485
Project: Firebird Core
Issue Type: Improvement
Components: API
Em sáb, 13 de fev de 2021 10:01, Mark Rotteveel
escreveu:
> 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
> >
