> > 2. If first field is larger than 31, assume format is yy-mm-dd.
> > (I'm not totally wedded to this, since it could be argued to be
> > allowing the input values to determine the interpretation, which
Well, just give people the choice by:
set date_input_heuristics to true;
the default being "false", perhaps.
> > is exactly the kind of heuristic that people objected to in the
> > dd/mm vs mm/dd discussion last month. It seems reasonable to me,
> > but it could be removed without affecting the rest of this proposal.)
I think it makes a lot of sense if combined with a switch
"Yes, I want heuristics".
> I am not excited about this, though you could say it is an extension of
> the 4-digit rule. However, I don't like that 30-03-03 is in 2003 and
> 32-03-03 is in the year 32AD. That seems error-prone to me. :-)
Well, but that's what the input means. Or, to be more precise,
that is what the "32-03-03" means. Either it is a data input
error (date_input_heuristics is false and input style is not
YMD) or it is 32AD (input style YMD and heuristics off OR
heuristics on and un-ambigous year field detected). Of course,
for ambigous data even heuristics==true should have to revert
back to strict checking and signal ambiguity if
non-resolvable.
Just my thoughts,
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346