Hi, I'm probably stating the obvious, but just in case.
There are two problematic areas to watch out for. One is that these units are not fixed length, their duration depends on the starting point. A year can be 365 or 366 days. A month can be 28-31 days. A minute can be 59-61 seconds (with the "right" timezones; in practice only 60 and 61 occurs so far). For example, date -d '2019/01/31 1 month' reports Mar 3 (overflows from Feb 28), and obviously further advancing by another month as '2019/03/03 1 month' reports Apr 3. However, date -d '2019/01/31 2 months' reports Mar 31. Can you guess what '2019/01/31 1 month 1 month' says? The other is around DST changes. E.g. with TZ=Europe/Budapest (after 2019/03/31 01:59:59 the next second was 03:00:00) what would '2019/03/31 1 day' report, and what would '2019/03/31 24 hours'? Combine with the previous problematic area: check what '2019/03/30 02:30:00 1 day', '2019/03/30 02:30:00 2 day' or '2019/03/30 02:30:00 1 day 1 day' says. I would guess that whatever coreutils's date plus glibc's localtime() and friends do in these tricky cases isn't documented, subject to change without notice at any time, and might easily differ across other Unixes. At least the second problem can be avoided if you use TZ=UTC for all your date calculations; especially if you only care about calendar days in a timezone-agnostic way, and no timestamp within. cheers, egmont On Tue, May 21, 2019 at 8:00 PM Peng Yu <[email protected]> wrote: > > Hi, > > For example, I want to calculate 5 years less a month from May 2018, > i.e., "2018/05", the result should be "2013/06". > > https://www.gnu.org/software/coreutils/manual/html_node/Examples-of-date.html > > I don't think the direct calculation of this kind of relative date is > possible with coreutiles' date command. Some kind of external > arithmetic calculation must be used. Is it so? > > -- > Regards, > Peng >
