On Mon, Jan 27, 2020 at 01:29:47PM -0300, Carlos Santos wrote:
> 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?
No, it's really simple digits based date-time like "2012-09-22 16:34:22".
getdate(3) is maybe another choice for future versions, for 2.35.1 is
parse_timestamp() good enough to avoid GPLv3.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
