On 24-10-2020 23:51, Adriano dos Santos Fernandes wrote:
Please create a ticket for this.
Done: http://tracker.firebirdsql.org/browse/CORE-6429
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
Em qui, 22 de out de 2020 09:34, Mark Rotteveel
escreveu:
> On a related note, given time zones are new in Firebird 4, I think we
> should be more strict about them and not introduce ambiguity in their
> syntax, and we should follow the SQL standard requirements, and always
> expect:
>
>
On 22/10/2020 09:33, Mark Rotteveel wrote:
>
> On a related note, given time zones are new in Firebird 4, I think we
> should be more strict about them and not introduce ambiguity in their
> syntax, and we should follow the SQL standard requirements, and always
> expect:
>
Agree.
Adriano
On 22-10-2020 13:09, Adriano dos Santos Fernandes wrote:
On 20/10/2020 08:42, Dmitry Yemanov wrote:
This is stil ambiguous.
This is valid in v3:
SQL> select timestamp '22 oct' from rdb$database;
CONSTANT
=
2020-10-22 00:00:00.
SQL> select
On 10/22/20 2:09 PM, Adriano dos Santos Fernandes wrote:
SQL> select timestamp '22 oct 20' from rdb$database;
CONSTANT
=
2020-10-22 00:00:00.
But now you can't easily know if 20 is a time zone or a year.
In this particular case that's known
On 20/10/2020 08:42, Dmitry Yemanov wrote:
> 20.10.2020 13:58, Vlad Khorsun via Firebird-devel wrote:
>
>>> AFAIU, it was discussed here in February 2018, thread "Valid date or
>>> not".
>>
>> I've re-read that thread quickly and I saw nor final decision, nor
>> proposition
>> to change (or break)
On 20-10-2020 12:40, Roman Simakov wrote:
вт, 20 окт. 2020 г. в 13:28, Mark Rotteveel :
Because documentantion here
(https://firebirdsql.org/en/firebird-date-literals/) says they are valid
separators.
Keep in mind, that link is an excerpt from Helen Borrie's Firebird Book
from 2004 (Firebird
20.10.2020 13:58, Vlad Khorsun via Firebird-devel wrote:
AFAIU, it was discussed here in February 2018, thread "Valid date or
not".
I've re-read that thread quickly and I saw nor final decision, nor
proposition
to change (or break) rules for traditional (legacy) date\time types
(without
вт, 20 окт. 2020 г. в 14:15, Vlad Khorsun via Firebird-devel
:
>I've re-read that thread quickly and I saw nor final decision, nor
> proposition
> to change (or break) rules for traditional (legacy) date\time types (without
> TZ).
Me too. Generally that discussion was focused on other
20.10.2020 13:43, Dmitry Yemanov wrote:
20.10.2020 13:40, Roman Simakov wrote:
Because documentantion here
(https://firebirdsql.org/en/firebird-date-literals/) says they are valid
separators.
Keep in mind, that link is an excerpt from Helen Borrie's Firebird Book
from 2004 (Firebird 1.5
20.10.2020 13:40, Roman Simakov wrote:
Because documentantion here
(https://firebirdsql.org/en/firebird-date-literals/) says they are valid
separators.
Keep in mind, that link is an excerpt from Helen Borrie's Firebird Book
from 2004 (Firebird 1.5 era). It is descriptive of what worked at
вт, 20 окт. 2020 г. в 13:28, Mark Rotteveel :
> > Because documentantion here
> > (https://firebirdsql.org/en/firebird-date-literals/) says they are valid
> > separators.
>
> Keep in mind, that link is an excerpt from Helen Borrie's Firebird Book
> from 2004 (Firebird 1.5 era). It is descriptive
On 20-10-2020 11:51, Dmitry Starodubov wrote:
Some string to date conversions that work in FB3 fail with an error in FB4:
SELECT cast('01 jan 1900' as timestamp) FROM rdb$database;
Statement failed, SQLSTATE = 22018
conversion error from string "01 jan 1900"
SELECT cast('01,jan,1900' as
Hello.
Some string to date conversions that work in FB3 fail with an error in FB4:
SELECT cast('01 jan 1900' as timestamp) FROM rdb$database;
Statement failed, SQLSTATE = 22018
conversion error from string "01 jan 1900"
SELECT cast('01,jan,1900' as timestamp) FROM rdb$database;
Statement
14 matches
Mail list logo
