[Toybox] what is date's -s option supposed to mean?

[Rob Landley]

On 07/28/2015 03:51 PM, enh wrote:
> (i don't care about this -- and didn't know it existed before today --
> but noticed it while fixing a bug i do care about, the patch for which
> i've already sent you...)
> 
> the toybox code seems to think -s lets you specify the format used
> when setting a time.

The thing is, +FORMAT is only display format. It's for _output_, not for
input. When you give date a string it has to parse as a date, the
gnu/dammit date is hardwired to only accept certain magic input formats.
(Well, it has a mostly undocumented "date -d @1234567890" that's
hardwired to accept unix time in seconds, but I only learned about that
recently. So my solution was general, and theirs was a special case to
add one more specific hardwired format because gnu.)

My first attempt was applying +FORMAT to input in certain circumstances,
because if you do:

  date +%s -d 1234567890

The behavior you should get seems obvious, although gnu gives you an
error message instead.

Unfortunately that didn't cut it because if you want to convert a date
from one format to another, and display the result rather than setting
the system clock, you have to specify the input format _and_ the output
format separately at the same time. So I needed a "format for input"
option. (-s not only isn't posix, it's what's mandated to happen if you
give posix an extra argument.)

(I think I was messing around with mbox conversion and hitting times
specified in multiple formats that needed to be regularized and
compared? I needed a tool to do that from the command line, and there
just wasn't one.)

> that doesn't seem to match the coreutils behavior.

No it doesn't. (Sigh. I had long discussions with somebody about this,
but I think it was in 2013 when I was up in Minnesota, and I'm not
finding it in my blog or the mailing list archive. Most likely it was on
irc?)

When Walter Harms added this feature to busybox a decade ago, he used -D
for it:

http://git.busybox.net/busybox/commit/coreutils/date.c?id=c5789a6e234c1ddec204cf65f319babb04ca6a47

I can change from -s to something else and add the completely useless -s
meaning back if you like? For people who actively hate posix...

> experiment suggests that -s takes an argument similar to
> -d/--date, which is described thus on the man page:

Bad sign you had to experiment. Toybox --help says:

    -s  +FORMAT for SET or -d (instead of MMDDhhmm[[CC]YY][.ss])

The SET referred to there is the one from the usage: line. Alas it's
hard to be simultaneously terse, obvious, and thorough when explaining
stuff. Looks like I need to make another stab at it?

I wanted to be able to convert an arbitrary date format _to_ another
arbitrary date format, and couldn't figure out how to beat that behavior
out of posix or gnu.

I didn't start from the gnu implementation here, I started from posix's
date spec, which has one of the more horribly written command descriptions:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html

I.E. you'll never tell from their usage line, but the last argument is
optional. If it's not there, display time. If it is there, set time. You
can have a +FORMAT argument that explicitly controls _output_ format,
but not input format. I tested several variants of beating this behavior
out of gnu date, and even went so far as to install the "info" command
to look at that documentation since they keep _not_ documenting stuff in
their man pages and nobody ever bothers to put info pages online because
nobody outside of gnu cares about them. I'm pretty sure the @date thing
was added since I dug (possibly in response to me asking people about
it, wouldn't be the first time).

> DATE STRING
>        The  --date=STRING  is  a mostly free format human readable date string
>        such as "Sun, 29 Feb 2004 16:21:42 -0800" or "2004-02-29  16:21:42"  or
>        even  "next Thursday".  A date string may contain items indicating cal‐
>        endar date, time of day, time zone, day of week, relative  time,  rela‐
>        tive date, and numbers.  An empty string indicates the beginning of the
>        day.  The date string format is more complex than is easily  documented
>        here but is fully described in the info documentation.
> 

Hence why I installed the info documentation. How do you parse a free
format human readable date string? Busybox had 4 random ones it tried in
order with no explanation of where they came from. I vaguely recall the
gnu/dammit version would go open some random file where you could list
formats in your order of preference.

Me, I went "let the user specify this" instead of magic heuristics.

Rob

 1438187978.0