> 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 formatting rules are:
1- A consistent non a-Z separator should be required. The exact separator
should not matter (but have no problem if a restricted set of characters is
defined)
2- Year part is always the last "position"
3- Any (a-Z) characters are considered part of the month abbreviation, also
allowing day/month and month/day. The abbreviation must be 3 characters. And
conform to English abbreviation.
4- in the absence of (a-Z) characters/month abbreviation, the order to the date
"parts" is day, month and year.
Using the above rules the following formats would be supported:
DD/MM/YY, DD/MM/YYYY, DDMMYY
DD MMM YY, DD MMM YYYY, DDMMMYY, DDMMMYYYY
MMM-DD-YY, MMM-DD-YYYY, MMMDDYY, MMMDDYYYY
Then I did some reading on the ISO 8601 date/time format (which aligns with SQL
standard), and realized that we had a problem! that format is it quite
specific, only allowing YYYY-MM-DD. {ignoring time component for the moment).
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 support for the
legacy date formats.
3- I would amend my rules to add explicit support for the YYYY-MM-DD (but not
YYYY-MMM-DD) format for legacy DATE and TIMESTAMP datatype.
Sean
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
