On 2018-02-28 19:26, Adriano dos Santos Fernandes wrote:
This thread become full of offtopic discussion... Discussion here is
about date/time separators, for consistency and correct handling of
time zone offsets.
As Firebird accepts everything (spaces, commas, minus, etc) as
separators, that is
> Exactly what do you mean with this? -MM-DD is already supported.
I wasn't sure it was -- it is not a string format that I/we use.
Sean
--
Check out the vibrant tech community on one of the world's most
engaging
On 28/02/18 15:42, Leyne, Sean wrote:
3- I would amend my rules to add explicit support for the -MM-DD (but not
-MMM-DD) format for legacy DATE and TIMESTAMP datatype.
This has been my standard format since the Y2k problems and flags in the
user code to switch D and M values if
On 2018-02-28 16:42, Leyne, Sean wrote:
3- I would amend my rules to add explicit support for the -MM-DD
(but not -MMM-DD) format for legacy DATE and TIMESTAMP datatype.
Exactly what do you mean with this? -MM-DD is already supported.
Mark
> Should this be considered a bug, i.e., separators should be necessary in this
> case (12-Mar-92, 12/Mar/92, 12.Mar.92)?
My initial reaction was yes, but when I started thinking about/listing my
"formatting rules" and came to realize that "no separator" was a
reasonable/logical extension.
28.02.2018 16:42, Leyne, Sean wrote:
Based on this, and considering legacy FB applications I propose the following:
1- The only acceptable string format for the new Date/Time with Timezone
datatypes should be the ISO/SQL standard
2- Only legacy DATE and TIMESTAMP datatype would maintain
some DDL statements can't be executed in one transaction
Key: CORE-5763
URL: http://tracker.firebirdsql.org/browse/CORE-5763
Project: Firebird Core
Issue Type: Bug
On 28-2-2018 10:00, Lester Caine wrote:
On 21/02/18 03:02, Adriano dos Santos Fernandes wrote:
As part of CORE-5750 problems, I found that Firebird considers '12Mar92'
as a valid date (1992-03-12).
Should this be considered a bug, i.e., separators should be necessary in
this case (12-Mar-92,
On 21/02/18 03:02, Adriano dos Santos Fernandes wrote:
As part of CORE-5750 problems, I found that Firebird considers '12Mar92'
as a valid date (1992-03-12).
Should this be considered a bug, i.e., separators should be necessary in
this case (12-Mar-92, 12/Mar/92, 12.Mar.92)?
I'd consider ANY
On 28/02/18 10:29, Mark Rotteveel wrote:
On 28-2-2018 10:54, Lester Caine wrote:
Technically, the SQL Standard knows only one format, and that is
(slightly simplified):
-MM-DD HH24:MI:SS.FF..+/-TZH:TZHM
While this is the 'standard' it has the same fundamental flaw that
it's use in
> 28.02.2018 16:42, Leyne, Sean wrote:
> > Based on this, and considering legacy FB applications I propose the
> following:
> >
> > 1- The only acceptable string format for the new Date/Time with
> > Timezone datatypes should be the ISO/SQL standard
> >
> > 2- Only legacy DATE and TIMESTAMP
Installation of Firebird 3.0.3 on SLES 12 SP3 fails with ''Could not find
acceptable ICU library"
-
Key: CORE-5764
URL:
27.02.2018 17:19, Rashid Abzalov wrote:
And what about enable/disable the regular system indexes?
Without this capability, system queries will continue to use regular
system indexes, instead of more suitable (for performance reasons in
specific cases) user indexes.
It's up to the optimizer
On 28-2-2018 10:54, Lester Caine wrote:
Technically, the SQL Standard knows only one format, and that is
(slightly simplified):
-MM-DD HH24:MI:SS.FF..+/-TZH:TZHM
While this is the 'standard' it has the same fundamental flaw that it's
use in other standards has. It has no way of
14 matches
Mail list logo
