Eric, much thanks for your detailed examination.
Am 15.03.2017 um 02:21 schrieb Eric Blake:
Let's try this with the new --debug option of 8.26
Great, but current version of my Ubuntu is 8.25
$ date --debug -d "$(($(date -r ChangeLog +%s)-$(date +%s))) seconds -2 months" date: parsed relative part: -5363514 seconds date: parsed relative part: -2 month(s) -5363514 seconds
Why not: date: parsed relative part: -5363514 seconds -2 month(s) A more simple example without touch: $ date +%F 2017-03-15 $ date -d "-20 day" +%F 2017-02-23 $ date -d "-20 day -2 month" +%F 2016-12-26 $ date -d "-2 month -20 day" +%F 2016-12-26 In the 2nd example I would expect: 2016-12-23
Yes, but I failed with (a) combining -r and -d and (b) setting an absolute starting point e.g.:What calculation are you trying to achieve? The inner $(()) computes the difference between two dates: the reference file timestamp, and the current time, resulting in a negative offset in seconds. The outer date computation (where I ran --debug) then sees only two relative values - a negative seconds offset, and a negative months offset, both applied from the current time as the starting point.Otherwise it seems impossible to correctly change the time stamp of a file relative to its current value.Wait - so you're trying to shift a file's time stamp by a fixed amount, such as by 2 months? Doesn't that imply that the outer date should see the file's timestamp as one of its starting points, rather than being left to start from the current time as its starting point?
$ date -d "$(date -r test) -2 month" date: ungültiges Datum »Di 10. Jan 22:39:00 CET 2017 -2 month“So I did this "trick", because I didn't see a chance to directly allow a reference file timestamp as starting point.
So what's wrong with: $ date --debug -d "Jan 1 1970 $(date -r ChangeLog +%s) seconds -2 months" date: parsed date part: (Y-M-D) 2017-01-01 date: parsed number part: year: 1970 date: parsed relative part: +1484176262 seconds date: parsed relative part: -2 month(s) +1484176262 seconds date: input timezone: -06:00 (set from system default) date: warning: using midnight as starting time: 00:00:00 date: starting date/time: '(Y-M-D) 1970-01-01 00:00:00 TZ=-06:00' date: warning: when adding relative months/years, it is recommended to specify the 15th of the months date: after date adjustment (+0 years, -2 months, +0 days), date: new date/time = '(Y-M-D) 1969-11-01 00:00:00 TZ=-06:00' date: '(Y-M-D) 1969-11-01 00:00:00 TZ=-06:00' = -5248800 epoch-seconds date: after time adjustment (+0 hours, +0 minutes, +1484176262 seconds, +0 ns), date: new time = 1478927462 epoch-seconds date: output timezone: -06:00 (set from system default) date: final: 1478927462.000000000 (epoch-seconds) date: final: (Y-M-D) 2016-11-12 05:11:02 (UTC0) date: final: (Y-M-D) 2016-11-11 23:11:02 (output timezone TZ=-06:00) Fri Nov 11 23:11:02 CST 2016 which is two months prior to the timestamp?
This example may work, because the shortness of february is not involved.
Wow, much thanks, I didn't know that touch (a) would allow relative dates and (b) would allow to combine -r and -d and even in the weird order of -d -r.Also, since you're using GNU date, you're probably using GNU touch, which means you can use touch -d instead of touch -t to set the time of the file, with a LOT less notational overhead, and in a reversible manner relative to a timestamp: $ : > foo $ touch -d '-2 months' -r foo foo $ ls -l foo -rw-rw-r--. 1 eblake eblake 0 Jan 14 19:19 foo $ touch -d '+2 months' -r foo foo $ ls -l foo -rw-rw-r--. 1 eblake eblake 0 Mar 14 20:19 foo
I'm leaving this open,
Thanks. So I see several points for enhancement: - Allow @seconds in -d option, even for touch. - Document the '@' syntax not only as example. - For date document if combination of -r -d (and others) is allowed. - For touch document if combination of -r -d (and others) is allowed. - For date allow combination of -r -d (maybe even more). - Calculate terms of -d option from left to right.
smime.p7s
Description: S/MIME Cryptographic Signature