NSDateComponentsFormatter 不支持大间隔
NSDateComponentsFormatter not supported large interval
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"
这是 Apple 的错误，还是我做错了什么？
引用日期为 1970 年 1 月 1 日的方法 timeIntervalSinceDate 导致了问题。
1970 + 68 = 2038
来自维基百科：
Year 2038 problem
The Year 2038 problem is an issue for computing and data storage
situations in which time values are stored or calculated as a signed
32-bit integer, and this number is interpreted as the number of
seconds since 00:00:00 UTC on 1 January 1970 ("the epoch"). Such
implementations cannot encode times after 03:14:07 UTC on 19 January
2038, a problem similar to but not entirely analogous to the "Y2K
problem" (also known as the "Millennium Bug"), in which 2-digit values
representing the number of years since 1900 could not encode the year
2000 or later. Most 32-bit Unix-like systems store and manipulate time
in this "Unix time" format, so the year 2038 problem is sometimes
referred to as the "Unix Millennium Bug" by association.
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"
这是 Apple 的错误，还是我做错了什么？
引用日期为 1970 年 1 月 1 日的方法 timeIntervalSinceDate 导致了问题。
1970 + 68 = 2038
来自维基百科：
Year 2038 problem
The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 ("the epoch"). Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the "Y2K problem" (also known as the "Millennium Bug"), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this "Unix time" format, so the year 2038 problem is sometimes referred to as the "Unix Millennium Bug" by association.