> 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 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
-
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 requir
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
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 very problematic to separate the time and timezone offset p
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 t
> 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 datat
Installation of Firebird 3.0.3 on SLES 12 SP3 fails with ''Could not find
acceptable ICU library"
-
Key: CORE-5764
URL: http://tracker.firebirdsql.org/browse/CORE-5764
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 suppor
> 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.
My
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
Components
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 other
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 indicatin
On 28/02/18 09:29, Mark Rotteveel wrote:
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 separator other than a space as an error when using
text months. '12Mar92' is at least consistent when spaces and extr
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, 12
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 s
16 matches
Mail list logo
