Util-Linux Archive on lore.kernel.org
 help / color / Atom feed
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
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

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 Zak  <kzak@redhat.com>

      reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 10:57 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 publically 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:

* 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 \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Util-Linux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/util-linux/0 util-linux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 util-linux util-linux/ https://lore.kernel.org/util-linux \
	public-inbox-index util-linux

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git