关于后端:令人困惑的-Go-timeAddDate

咱们常常会应用 Go time 包 AddDate()，对日期进行计算。而它失去的后果，可能会往往超出咱们的“预期”。（为什么预期要打引号，因为咱们的预期可能是含糊、偏差的）。

假如，明天是 10 月 31 日，是 10 月的最初一天，咱们想通过 AddDate()计算下个月的最初一天。

today := time.Date(2022, 10, 31, 0, 0, 0, 0, time.Local)
nextDay := today.AddDate(0, 1, 0)
fmt.Println(nextDay.Format("20060102"))

// 输入：20221201

后果输入：20221201，而非咱们预期的下个月最初一天 11 月 30 日。

Go Time 包中是这么解决的：

AddDate() 对月份 +1，即变成了 11-31，换算成对应的天数、最终换算成对应的纳秒数存储在 Time 对象中；
输入时，Format()将输入规范的日期，Time 中的纳秒会转为 12-01，而不是 11-31，因为这天并不存在；

只有是波及到大小月的最初一天都会呈现这个问题。

today := time.Date(2022, 3, 31, 0, 0, 0, 0, time.Local)
d := today.AddDate(0, -1, 0)
fmt.Println(d.Format("20060102"))
// 20220303

today := time.Date(2022, 3, 31, 0, 0, 0, 0, time.Local)
d := today.AddDate(0, 1, 0)
fmt.Println(d.Format("20060102"))
// 20220501

today := time.Date(2022, 10, 31, 0, 0, 0, 0, time.Local)
d := today.AddDate(0, -1, 0)
fmt.Println(d.Format("20060102"))
// 20221001

today := time.Date(2022, 10, 31, 0, 0, 0, 0, time.Local)
d := today.AddDate(0, 1, 0)
fmt.Println(d.Format("20060102"))
// 20221201

看一下 Go Time 包具体源码，仍以结尾 10-31 + 1 month 的例子为用例。
AddDate()，首先对 month+1，而后调用 Date() 解决。

// time/time.go

func (t Time) AddDate(years int, months int, days int) Time {year, month, day := t.Date() // 获取以后年月日
    hour, min, sec := t.Clock() // 获取以后时分秒
    return Date(year+years, month+Month(months), day+days, hour, min, sec, int(t.nsec()), t.Location())
}

Date()中此时传入的参数是

year 2020
month 11
day 31
hour、min、sec、nsec 为运行时的时分秒纳秒

d 计算的是相对纪元到明天之前的天数：
**d = 往年之前的天数 + 年初到当月之前的天数 + 月初到当天之前的天数；**
最终，将 d 转换成纳秒 + 当天通过的纳秒 存储在 Time 对象中。

// time/time.go

func Date(year int, month Month, day, hour, min, sec, nsec int, loc *Location) Time {
    ……

    // Compute days since the absolute epoch.
    d := daysSinceEpoch(year)

    // Add in days before this month.
    d += uint64(daysBefore[month-1])
    if isLeap(year) && month >= March {d++ // February 29}

    // Add in days before today.
    d += uint64(day - 1)

    // Add in time elapsed today.
    abs := d * secondsPerDay
    abs += uint64(hour*secondsPerHour + min*secondsPerMinute + sec)

    ……
    return t
}

对 Date() 输出 2022-11-31 和输出 2022-12-01，将失去同样的 d（天数）。两者底层存储的时候都是一样的数据，Format() 时将2022-11-31 的 Time 格式化成 2022-12-01也就不例外了，输入当然要显示让人看得懂的惯例规范日期嘛。

// 2022-11-31
d = 2022 年之前的天数 + 1 月到 10 月的总天数 + 30 天

// 2022-12-01
d = 2022 年之前的天数 + 1 月到 11 月的总天数 + 0 天
  = 2022 年之前的天数 + 1 月到 10 月的总天数 + 30 天 + 0 天

你甚至能够往 Date() 输出非标准日期 2022-11-35，它和规范日期 2022-12-05，将失去同样的 d（天数）。
“非标准日期”和“规范日期”就像天平的两边，尽管模式不一样，但他们理论的品质（d 天数）是一样的。 记住这句话，前面有用。

咱们弄清楚了原理，但依然不能承受这个后果。这样的后果是 Go 的 bug 吗？还是 Go Time 包偷懒了？
然而并不是，恰好是咱们的“预期”呈现了问题。
失常来说，咱们预期 10-30 + 1 month是 11-30 日，这很正当。那咱们为什么还期待 10-31 + 1 month 也是 11-30 日？仅仅因为 10-31是以后月的最初一天，咱们也期待 +1 month 后是下个月的最初一天吗？
10-30 和 10-31 两个日期相差一天，进行同样的 +1 month 操作后，就变成为了同一天。这就像 1 + 10 = 2 + 10 一样的后果，这显然不合理。
Go 目前的处理结果是正确的，并且他在 AddDate() 正文中也注明了会解决“溢出”的状况。况且，不止 Go 语言这么解决，PHP 也是这么解决的，见鸟哥文章令人困惑的 strtotime – 风雪之隅。

情理我都懂，但我就是想获取上 / 下一个月的最初一天怎么办？
利用后面源码分析阶段，提到的“天平原理”，就能拿到咱们想要的后果。

today := time.Date(2022, 10, 31, 0, 0, 0, 0, time.Local)
d := today.Day()

// 上个月最初一天
// 10-00 日 等于 9-30 日
day1 := today.AddDate(0, 0, -d)
fmt.Println(day1.Format("20060102"))

// 下个月最初一天
// 12-00 日 等于 11-30 日
day2 := today.AddDate(0, 2, -d)
fmt.Println(day2.Format("20060102"))

// 20220930
// 20221130

最后，发现这个问题是看鸟哥文章，过后认为那是 PHP 的“坑”，并没有深刻思考过。现在，在 Go 语言再次遇到这个问题，从新思考，发现日期函数本应该就那么设计，是咱们对日期函数了解不够，产生了谬误的“预期”。

文章来自令人困惑的 Go time.AddDate

关于后端:令人困惑的-Go-timeAddDate

引例

源码剖析

预期偏差

怎么解决

结语