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

[enh]

On Wed, Jul 29, 2015 at 9:39 AM, Rob Landley <rob at landley.net> wrote:
> 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.)

(i think that kind of thing is a sign it's time to switch to perl/python/ruby!)

>> 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...

no one's hit this in practice yet, but that sounds like the right
approach to me. the closer we get to "behaves like coreutils", the
more confusing the exceptions become.

>> 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?

no, you misunderstand: the toybox documentation was great, it was just
obviously documenting something completely different from coreutils,
and it was a PITA trying to find useful documentation for coreutils'
behavior. i'm describing coreutils' -s here.

(see how confusing it is when the same option in the same command
behaves completely differently :-P )

> 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.

which makes sense to me, but having -s mean something completely
different to coreutils is going to be a problem as long as most people
are porting from coreutils to toybox.

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1438190021.0