True. It was mostly a plea for some (findable) documentation.
In truth, my most common usage is more like:
touch -t $(date --date@$(( $(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 <j...@meyering.net> wrote:
> On Wed, Feb 4, 2015 at 9:25 AM, Bruce Korb <bruce.k...@gmail.com> 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
