|Subject:||Re: date grief
|Date:||Sun, 31 Dec 2017 07:10:54 +1000
|From:||Bernie van't Hof <email@example.com>
Today I looked at "FRED 32 + 2" and its variants in a text column,
exposing a bunch of issues.
I said I wouldn't come back to this thread, but, as I proceed with the
qbe parser and pdox's "artificial intelligence", I am reminded of:
Very frustrating, but never mind. Will just have to do better.
On 3/12/17 11:32 am, Bernie van't Hof wrote:
> Some stuff I just can't remember and I need to lean on ya'all to
> preserve my sanity ...
> Assume pdox set to default date format DD-Mon-YY
> 1. 3-Mar-16 does not fetch field of 3-Mar-2016,
> 3-Mar-2016 works OK.
> 2. 4-Mar-2016-1 or 3/4/2016-1 correctly do 3 mar 2016
> 3. qbe will read some date values regardless of default date format
> eg 3.3.2016 or 3/3/2016 work as above
> 2016.3.3 gives "missing comma" (albeit appears to be valid YY.MM.DD)
> 16.3.3 or 3/3/16 produce no error but doesn't fetch reqd row.
> (Probably per 1. above).
> I can see that having the year as YYYY makes it possible to resolve
> ambiguities, but what about ..16 ? If format dd-mmm-yyyy assumed is
> easy. But what happens to Europeans with default format dd.mm.yy or
> yy.mm.dd ? Only in America does mm/dd/yy make any sense ;)
> Does pdoxwin have these issues as well?
> - Bernie
> PS Is the plural of "ya'all" really "ya'all ya'all"?