Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Leyne, Sean
> 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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Mark Rotteveel
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 -

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Lester Caine
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Mark Rotteveel
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Leyne, Sean
> 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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Dimitry Sibiryakov
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Leyne, Sean
> 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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Lester Caine
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Mark Rotteveel
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Lester Caine
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Mark Rotteveel
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

Re: [Firebird-devel] Valid date or not

2018-02-28 Thread Lester Caine
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

Re: [Firebird-devel] Valid date or not

2018-02-22 Thread Adriano dos Santos Fernandes
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

Re: [Firebird-devel] Valid date or not

2018-02-22 Thread Dmitry Yemanov
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

Re: [Firebird-devel] Valid date or not

2018-02-22 Thread Mark Rotteveel
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

Re: [Firebird-devel] Valid date or not

2018-02-22 Thread Alex Peshkoff via Firebird-devel
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