On Tue, Jan 28, 2020 at 07:24:13PM +0000, Sami Kerola wrote:
> On Mon, 27 Jan 2020 at 20:22, Karel Zak <kzak@xxxxxxxxxx> wrote:
> > 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.
>
> This will most likely end up causing an ABI breakage so I think the best
> option is the least complicated time format, that is what parse_timestamp()
> provides.
IMHO current solution with #ifdefs is good enough for mainstream
hwclock users, the minority with gplv3-free requirement has to be more
careful with date/time formats... We need to describe it in the man
page and add some advice for portability, because the current
situation ("we support whatever format") is horrible commitment for
future.
Anyway, extend parse_timestamp() to support month and day names would
be nice for another tools too.
> In case arbitrary format really must be supported then I think the best
> option is to parse_timestamp() and if that fails call getdate() as well.
or add getdate() as the last possibility in parse_timestamp() :-)
> That said I have no idea how to write instructions to manual page about
> DATEMSK environment variable and strptime() formats without causing
> new-to-linux users to wonder why simple things must be so hard.
Good point. Frankly I have never seen getdate() in any code and for
good reasons coreutils guys replaced this function by own code.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
