On 2018-02-05 08:12:21 -0500, Roberto C. Sánchez wrote: > On Mon, Feb 05, 2018 at 02:07:47PM +0100, 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? > > > It is equally common, perhaps even more so, that buggy behavior is > retained (especially if it is not harmful) and that "correct" behavior > require a switch or setting. I am not personally affected by this, as > far as I know, but as a software developer I can certainly understand > wanting to retain backward compatibility, even when it is buggy.
It might be harmful because one silently gets a wrong date. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
