From: Karel Zak <kzak@redhat.com>
To: kerolasa@gmail.com
Cc: Carlos Santos <unixmania@gmail.com>,
util-linux <util-linux@vger.kernel.org>
Subject: Re: [ANNOUNCE] util-linux v2.35
Date: Thu, 30 Jan 2020 12:17:53 +0100 [thread overview]
Message-ID: <20200130111753.moen7ulzaz2jc5fh@ws.net.home> (raw)
In-Reply-To: <CAG27Bk0K-p+9eqUp8H+=-qrUuaEeiSHHsj7t9BA+fyRAwfVY3Q@mail.gmail.com>
On Tue, Jan 28, 2020 at 07:24:13PM +0000, Sami Kerola wrote:
> On Mon, 27 Jan 2020 at 20:22, Karel Zak <kzak@redhat.com> 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@redhat.com>
http://karelzak.blogspot.com
prev parent reply other threads:[~2020-01-30 11:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-21 10:57 [ANNOUNCE] util-linux v2.35 Karel Zak
2020-01-24 19:16 ` Carlos Santos
2020-01-25 10:51 ` Karel Zak
2020-01-25 11:19 ` Carlos Santos
2020-01-26 16:59 ` J William Piggott
2020-01-26 17:50 ` Carlos Santos
2020-01-27 16:13 ` Karel Zak
2020-01-27 16:38 ` Carlos Santos
2020-01-27 20:18 ` Karel Zak
2020-01-27 13:34 ` Karel Zak
2020-01-27 13:40 ` Karel Zak
2020-01-27 15:25 ` Karel Zak
2020-01-27 16:29 ` Carlos Santos
2020-01-27 20:21 ` Karel Zak
2020-01-28 19:24 ` Sami Kerola
2020-01-30 11:17 ` Karel Zak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200130111753.moen7ulzaz2jc5fh@ws.net.home \
--to=kzak@redhat.com \
--cc=kerolasa@gmail.com \
--cc=unixmania@gmail.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).