On Monday, February 05, 2018 08:07:47 AM Vincent Lefevre wrote: > On 2018-02-04 08:22:23 -0500, Michael Stone wrote: > > On Mon, Feb 05, 2018 at 12:48:45AM +1300, Richard Hector wrote: > > > In which case, it should refuse to accept '4/2/2018' at all, right? > > > > It can't, that would break working scripts. This is the heart of the > > problem: we know the parser is horrible, confusing, and irregular, but > > any attempt to change it will break lots of stuff that depends on the > > current brokenness. > > It is not rare that the behavior of utilities change and break > scripts. So, why not here, in particular for a good reason?
I'm not really going to answer the question, I think MIke Stone has answered it for you. The way forward would seem (to me) to be to create a new date function (ndate?) (or a new option to date) that provides the desired better functionality. I assume (I know) that the license for date is some free / open source license that would allow you to incorporate the old code into a new function (probably with appropriate citation / credit) and then add / modify / delete code as desired. OK, I will say one thing--I suspect this is something like the (forget what they called it)--the year 2000 problem--there is code that people (and companies depend on) that is so old that the maintainers are long gone, thus breaking that old function wouild be a very bad thing.
