On 03/06/2020 12:58, Mark Rotteveel wrote:
That is what you can expect when linking to documentation on a branch
called 'work' (which, afaik, was deleted a very long time ago), which
implies it's transient.
It had been used in relation to a previous thread and was the only link
I could see
On 2020-06-03 12:51, Lester Caine wrote:
On 03/06/2020 09:24, Alex Peshkoff via Firebird-devel wrote:
Has
https://github.com/FirebirdSQL/firebird/blob/work/time-zone-support/doc/sql.extensions/README.time_zone.md
Been replaced with something more up to date?
https://github.com/FirebirdSQL/fir
On 2020-06-02 23:32, Adriano dos Santos Fernandes wrote:
On 02/06/2020 16:45, Mark Rotteveel wrote:
Documentation should be improved for this case too.
This essentially means that
select * from atable where sometimecolumn > current_time;
will yield different results when the time zone is 'Eu
On 03/06/2020 09:24, Alex Peshkoff via Firebird-devel wrote:
Has
https://github.com/FirebirdSQL/firebird/blob/work/time-zone-support/doc/sql.extensions/README.time_zone.md
Been replaced with something more up to date?
https://github.com/FirebirdSQL/firebird/blob/master/doc/sql.extensions/READM
On 03/06/2020 04:10, Alex Peshkoff via Firebird-devel wrote:
> On 2020-06-03 00:17, Dimitry Sibiryakov wrote:
>> 02.06.2020 21:45, Mark Rotteveel wrote:
>>> I think that is extremely confusing, and not acceptable.
>>
>> That's why everyone was given several years to replace CURRENT_TIME
>> with L
On 2020-06-03 10:56, Lester Caine wrote:
On 03/06/2020 08:23, Lester Caine wrote:
On 02/06/2020 22:17, Dimitry Sibiryakov wrote:
02.06.2020 21:45, Mark Rotteveel wrote:
I think that is extremely confusing, and not acceptable.
That's why everyone was given several years to replace
CURRENT
On 03/06/2020 08:23, Lester Caine wrote:
On 02/06/2020 22:17, Dimitry Sibiryakov wrote:
02.06.2020 21:45, Mark Rotteveel wrote:
I think that is extremely confusing, and not acceptable.
That's why everyone was given several years to replace CURRENT_TIME
with LOCALTIME and don't use TIME WI
On 02/06/2020 22:17, Dimitry Sibiryakov wrote:
02.06.2020 21:45, Mark Rotteveel wrote:
I think that is extremely confusing, and not acceptable.
That's why everyone was given several years to replace CURRENT_TIME
with LOCALTIME and don't use TIME WITH TIMEZONE at all.
Has
https://github
On 2020-06-03 00:17, Dimitry Sibiryakov wrote:
02.06.2020 21:45, Mark Rotteveel wrote:
I think that is extremely confusing, and not acceptable.
That's why everyone was given several years to replace CURRENT_TIME
with LOCALTIME and don't use TIME WITH TIMEZONE at all.
Yes. What we defini
On 02/06/2020 16:45, Mark Rotteveel wrote:
> On 02-06-2020 21:34, Adriano dos Santos Fernandes wrote:
>> On 02/06/2020 16:11, Mark Rotteveel wrote:
>>> Maybe it is better if CURRENT_TIME doesn't use the named zone, but
>>> instead always uses an offset based value.
>>>
>> I'm not sure it is. This w
02.06.2020 21:45, Mark Rotteveel wrote:
I think that is extremely confusing, and not acceptable.
That's why everyone was given several years to replace CURRENT_TIME with LOCALTIME and
don't use TIME WITH TIMEZONE at all.
--
WBR, SD.
Firebird-Devel mailing list, web interface at
https:
On 02-06-2020 21:34, Adriano dos Santos Fernandes wrote:
On 02/06/2020 16:11, Mark Rotteveel wrote:
Maybe it is better if CURRENT_TIME doesn't use the named zone, but
instead always uses an offset based value.
I'm not sure it is. This would create other inconsistencies
(cast(current_timestamp
On 02/06/2020 16:11, Mark Rotteveel wrote:
> The recent changes to fix the derivation of TIME WITH TIME ZONE to
> 2020-01-01 has weird consequences. In summer time, the value of for
> example CURRENT_TIME is now off by 1 hour when looking at the UTC time
> value.
>
> This leads to the following con
13 matches
Mail list logo
