On Mon, Jan 27, 2020 at 1:13 PM Karel Zak <kzak@xxxxxxxxxx> wrote: > > On Sun, Jan 26, 2020 at 11:59:59AM -0500, J William Piggott wrote: > > You do realize that I had to heavily modify that file to remove its > > gnulib dependencies (because you said no to gnulib). If I recall > > I know, this is why we keep it in the tree (and thanks for all the > work!). > > > correctly I had newer and older versions to chose from and picked that > > one due to it having the most bugs fixed while still being practical to > > strip its gnulib dependence. > > > > The reasons for making the change were: > > * remove hwclock's dependence on date(1) > > * remove an insecure call to date(1) > > * I thought there would be to many complaints if the accepted input > > date formats were changed > > > > As to the last bullet point; personally I think having the --date option > > accept every date syntax know to history is nonsense. > > Yes, I agree it's probably overkill. > > > Or you could just use the existing utillinux date parser. > > This is what I have implemented for --disable-hwclock-gplv3 to have > anything ASAP for the next 2.35.1 update... Maybe we can make it the > default for the next release v2.36 and later remove the gnulib code at > all. > > > The question is, do you want to deal with any pushback for > > changing the long established accepted --date formats? > > IMHO the existing utillinux date parser is good enough, but I have no > clue how people use --date. This is a bit disturbing. People should know in advance what date/time formats hwclock supports. They should be described in the man page, at least in a simple statement like “the suported date formats are the same as foo(3)”. Leaving it to be guessed by users, either reading the source code or testing at run-time does not make sense. The man page does not even mention Documentation/parse-date.txt. -- Carlos Santos <unixmania@xxxxxxxxx>
