NSDateComponents格式化程序不支持大间隔

Question

let date = NSDate()
let future = NSDate.distantFuture()
let f = NSDateComponentsFormatter()
f.unitsStyle = .Full
f.allowedUnits = [.Year, .Month, .Day]
f.stringFromTimeInterval(future.timeIntervalSinceDate(date))

结果是"-57 years, 0 months, 26 days"这是错误的。

我认为这可能是由溢出引起的，所以我尝试了较小的数字，发现这种奇怪的行为始于 69 年的间隔

let date = NSDate()
let sixtyEightYears = NSCalendar.currentCalendar().dateByAddingUnit(.Year, value: 68, toDate: date, options: NSCalendarOptions())!
let sixtyNineYears = NSCalendar.currentCalendar().dateByAddingUnit(.Year, value: 69, toDate: date, options: NSCalendarOptions())!
let f = NSDateComponentsFormatter()
f.unitsStyle = .Full
f.allowedUnits = [.Year, .Month, .Day]
future.timeIntervalSinceDate(date)
sixtyEightYears.timeIntervalSinceDate(date) // 2145916800
sixtyNineYears.timeIntervalSinceDate(date) // 2177452800
f.stringFromTimeInterval(sixtyNineYears.timeIntervalSinceDate(date)) // "-67 years, 1 month, 6 days"

这是苹果的错误，还是我做错了什么？

Answer 1

引用

日期为 1970 年 1 月 1 日的方法timeIntervalSinceDate会导致此问题。

1970 + 68 = 2038

来自维基百科：

2038年问题

2038年问题是计算和数据存储的问题将时间值存储或计算为已签名的情况32 位整数，此数字被解释为自 1970 年 1 月 1 日 00：00：00 UTC（"纪元"）以来的秒数。这样实现无法在 1 月 19 日 03：14：07 UTC 之后编码时间2038年，一个类似于但不完全类似于"Y2K"的问题问题"（也称为"千年虫"），其中 2 位数值表示自 1900 年以来的年数无法对年份进行编码2000 或更高版本。大多数32位类Unix系统存储和操作时间在这种"Unix时代"格式中，所以2038年的问题有时是被协会称为"Unix Millennium Bug"。

全文：2038年问题