ios - NSDateComponentsFormatter 不支持大间隔

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 年，0 个月，26 天"，这是错误的。

我认为这可能是溢出引起的，所以我尝试了较小的数字，发现这种奇怪的行为从 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"

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

Answer 1

引用日期为 1970 年 1 月 1 日的方法 timeIntervalSinceDate 导致了问题。

1970 + 68 = 2038

来自维基百科:

Year 2038 problem

The Year 2038 problem is an issue for computing and data storagesituations in which time values are stored or calculated as a signed32-bit integer, and this number is interpreted as the number ofseconds since 00:00:00 UTC on 1 January 1970 ("the epoch"). Suchimplementations cannot encode times after 03:14:07 UTC on 19 January2038, a problem similar to but not entirely analogous to the "Y2Kproblem" (also known as the "Millennium Bug"), in which 2-digit valuesrepresenting the number of years since 1900 could not encode the year2000 or later. Most 32-bit Unix-like systems store and manipulate timein this "Unix time" format, so the year 2038 problem is sometimesreferred to as the "Unix Millennium Bug" by association.

全文:Year 2038 problem