Re: policy around 'wontfix' bug tag

[rhkramer@gmail.com]

On Monday, February 05, 2018 10:02:50 AM Michael Stone wrote:
> On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkramer@gmail.com wrote:
> >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.
> 
> IIRC it started out as a YACC function in the late 80s, and is now a
> Bison (YACC+GNU extensions) library. There are still people who work on
> it--the debug option added a couple of years ago has made it *much*
> easier to understand why it does the things that it does. I'm not sure
> that if I were implementing a new option I'd use the bison code at all
> (it does probably limit the contributor pool). The bigger issues aren't
> the choice of implementation language, they're 1) getting buy-in on what
> the replacement should look like and 2) getting people to use something
> different. It's tough, because almost every linux system out there has
> date(1) with the existing -d parser, and it's easier to assume that's
> there than to use something else. (E.g., it's possible to use python or
> perl or other scripting language one-liners with any number of date
> libraries to add much more maintainable date handling to their scripts,
> but most people just stick with the date(1) they know rather than using
> one of the alternatives.)

Thanks for the (interesting, educational, and valid) response, but, for the 
record, I was trying to refer to all the scripts and such that use the date 
function rather than the coding of the date function itself.