On Monday, February 05, 2018 10:02:50 AM Michael Stone wrote: > On Mon, Feb 05, 2018 at 09:11:23AM -0500, rhkra...@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.
