我刚刚看了这个问题。第一个答案说明了如何直接从 date 命令获取未来日期。为什么不能只使用文本操作来增加日期？基本上：
date | # increment the time string by some amount here
我不熟悉awk或sed否则我会给一个更好的例子。
编辑：所以基本上没有技术原因？只是便携性和它比看起来更难的事实？
你可以，但它变得复杂。如果您有一个以秒为单位的日期，例如自 1970 年 1 月 1 日星期四午夜（POSIX 时间）以来经过的秒数，则添加一分钟相对容易：
$ date +%s
1379385111
$ date +%s | awk '{print "Current time is",$1,"soon will be", $1+60}'
Current time is 1379385275 soon will be 1379385335
很好，但如果你想用人类可读的时间来做这件事怎么办？如果您想增加 4 个月零 2 周怎么办？在几秒钟内计算它很痛苦，解释这样的日期也不容易。例如，什么日期411174000代表1？
你会如何增加Sun 12 Dec 1936，比如说，3 周？如果不允许使用日期操作库，这是一个令人惊讶的棘手问题。考虑将所有日期转换为秒然后相加，请记住，有些月份有 30 天，其他月份有 31 天，更不用说二月和闰年了。这真的不是一个小问题。这就是为什么大多数编程语言都有日期操作库（例如Perl或C）。
最重要的是，date可以处理像tomorrow或这样的日期，
Oct 18 2017并且可以添加和减去它们并返回一个人类可读的日期而不是一串数字。
既然标准date程序使这变得如此简单，为什么我们要重新发明轮子呢？
1现在是 1983 年 1 月 12 日星期三 00:00:00 CET
除了一个经过深思熟虑的图书馆之外，用任何东西来操纵时间和日期都是一个坏主意。看似微不足道的问题很快就会变成主要的复杂性问题，例如夏令时、闰年、闰秒、时区等。
程序员不断地想，“哦，我可以做一两个快速的功能来做到这一点”，而且你不必回顾最近发生的 Apple 开发人员认为这一点并且没有正确处理问题的事件。夏令时转换正确。
摘抄
几个小时前，当时钟从凌晨 1:59 向前移动到凌晨 3:00 时，夏令时 (DST) 在美国开始了。
但是，一些 iPhone 用户报告了 DST 更改的各种问题。
TUAW 报道：
一些读者报告说，昨晚他们的 iPhone 时钟并没有像预期的那样向前跳一个小时，而是实际上向错误的方向移动了 - 一个小时 - 因为自动时区调整不稳定。纳什维尔的一位读者有一部认为他处于山区时间的电话；佛罗里达电话中的一位读者确信应该是芝加哥时间。我们的同事 Mel Martin 住在亚利桑那州，那里大部分时间根本不遵守夏令时；尽管如此，他的手机（具有自动时区设置和位置设置）错误地向前跳了一个小时。
不要被问题表面上的简单性所诱惑，使用库！