I have also been having problems with the use of the TIME WITH TIME ZONE
type and have been holding back on posting on the issue until I came up
with a suitable proposal. I wrote down my thoughts on the issue a few
weeks ago and have appended them to the end of this EMail - at the time
of writi
On 2020-05-18 13:31, Adriano dos Santos Fernandes wrote:
Do you have an alternative (that do not broke things), better than use
fixed date (as Oracle does with 0001-01-01 and it even more broke
behavior) or a recent date?
Telling true I have bug desire to answer that error 'Invalid
operation' s
On 18/05/2020 04:00, Alex Peshkoff via Firebird-devel wrote:
> On 2020-05-16 05:22, Adriano dos Santos Fernandes wrote:
>> On 15/05/2020 12:46, Mark Rotteveel wrote:
>>> The decision to use 2020-01-01 as date for some of the time with time
>>> zone conversion leads to, in my opinion, confusing beha
On 2020-05-16 05:22, Adriano dos Santos Fernandes wrote:
On 15/05/2020 12:46, Mark Rotteveel wrote:
The decision to use 2020-01-01 as date for some of the time with time
zone conversion leads to, in my opinion, confusing behaviour:
select
time'13:25:32.1235 Europe/Amsterdam' at time zone 'ut
On 15/05/2020 12:46, Mark Rotteveel wrote:
> The decision to use 2020-01-01 as date for some of the time with time
> zone conversion leads to, in my opinion, confusing behaviour:
>
> select
> time'13:25:32.1235 Europe/Amsterdam' at time zone 'utc' as t1,
> cast(time'13:25:32.1235 Europe/Amster
The decision to use 2020-01-01 as date for some of the time with time
zone conversion leads to, in my opinion, confusing behaviour:
select
time'13:25:32.1235 Europe/Amsterdam' at time zone 'utc' as t1,
cast(time'13:25:32.1235 Europe/Amsterdam' as timestamp with time
zone) at time zone 'utc'
