Re: [PATCH] lib/parse-datetime.y: Add ability to parse output of GNU date(1)

[Bruce Korb]

True.  It was mostly a plea for some (findable) documentation.
In truth, my most common usage is more like:

    touch -t $(date address@hidden(( $(stat -c %Y file1) + 10 ))
+%Y%m%d%H%M.%S ) file2

Still, I use such constructs rarely enough that I don't know what's reasonable.
An example for use in "touch" would be nice:

     Display date suitable for use with touch(1):
         $ date --date @$seconds_since_epoch +%Y%m%d%H%M.%S

This:

    $ date --date @$seconds --format=touch

is probably a touch too much, but would be easier to remember.

On Wed, Feb 4, 2015 at 10:05 AM, Jim Meyering <address@hidden> wrote:
> On Wed, Feb 4, 2015 at 9:25 AM, Bruce Korb <address@hidden> wrote:
>> On 02/02/15 09:27, Pádraig Brady wrote:
>>>
>>> On 02/02/15 16:41, Chris Lamb wrote:
>>>>
>>>> We are currently in a funny situation where GNU date can't parse its own
>>>> output:
>>>>
>>>>    $ date --date="$(date)"
>>>>    date: invalid date 'Mon  2 Feb 16:37:46 GMT 2015'
>>
>>
>>> I don't think this will work as the output from date(1) is ambiguous.
>>> For example locales change change the output order, and names.
>>> In your example, date(1) can parse US locale default format, but not UK:
>>>
>>> $ date -d"$(LC_TIME=en_GB date)"
>>> date: invalid date 'Mon  2 Feb 17:23:25 GMT 2015'
>>
>>
>> It would still be useful to make the ways for doing this more readily known.
>> e.g. in examples:
>>
>>   touch -t $(date --date @$(( $(date +%s) + 10 )) +%Y%m%d%H%M.%S) file
>>
>> set the modify time of "file" to 10 seconds from now.  It's a little obtuse.
>
> If you are willing to rely on GNU date's --date=... option,
> you can set FILE's mtime to 10 seconds in the future more concisely with this:
>
>   touch -d '10 seconds' FILE