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) rules for traditional (legacy) date\time types >> (without TZ). > > The tracker ticket (CORE-5750) mentions the problem with spaces inside > the literal. If time parts are separated by spaces, it's hard to guess > whether the final part is TZ or milliseconds, AFAIU. The final > decision is also documented in that ticket. > > While I agree that breaking things is usually bad, time '10 20 30' or > time '10,20,30' look so terribly wrong to me, so personally I support > breaking them ;-) The same for date with commas. The only "broken" > format I agree to consider useful is '20 Oct 2020'. Given that > space-parsing problems appear inside the time part, perhaps it could > be re-allowed for dates (only).
This is stil ambiguous. This is valid in v3: ---- SQL> select timestamp '22 oct' from rdb$database; CONSTANT ========================= 2020-10-22 00:00:00.0000 SQL> select timestamp '22 oct 20' from rdb$database; CONSTANT ========================= 2020-10-22 00:00:00.0000 ---- But now you can't easily know if 20 is a time zone or a year. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
