> 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
> 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
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
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
Em 22/02/2018 12:39, Dmitry Yemanov escreveu:
> 22.02.2018 16:41, Alex Peshkoff 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
22.02.2018 16:41, Alex Peshkoff 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)?
Let's better treat it as standar
On 22-2-2018 14:33, 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 argue that we
On 02/22/18 16:33, Adriano dos Santos Fernandes wrote:
Hi!
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)?
Let's better
17 matches
Mail list logo