On Mon, Jan 27, 2020 at 10:40 AM Karel Zak <kzak@xxxxxxxxxx> wrote: > > On Mon, Jan 27, 2020 at 02:34:38PM +0100, Karel Zak wrote: > > On Fri, Jan 24, 2020 at 04:16:47PM -0300, Carlos Santos wrote: > > > I noticed that it comes due to sys-utils/hwclock-parse-date.y, which > > > was taken from gnulib. Would it be possible to take the file from an > > > previous version of gnulib that was still under GPLv2? > > > > I have checked it again and all history of the file in git is with v3, > > and import old version also means import many bugs.... > > > > Maybe the best would be to use our lib/timeutils.c:parse_timestamp(). > > It does not provide support for so many date-time formats, but the > > basic format like "2012-09-22 16:34:22" (and subsets) is supported. > > > > IMHO it's better to introduce a small backward compatibility issue than > > rely on hwclock-parse-date.y or execute date(1) like old versions. > > or we can use #ifdef to keep it backwardly compatible for normal > distros where v3 is not problem and lib/timeutils.c:parse_timestamp() > with v2 for the rest ... at least for v2.35.1. Does parse_timestamp support localization, like getdate(3) does? -- Carlos Santos <unixmania@xxxxxxxxx>
