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 years, 0 months, 26 days"ですが間違っています。

私は、これは、オーバーフローから原因かもしれないと思ったので、私は小さい番号を試してみて、

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" 

間隔69年の時点で、この奇妙な行動開始が、これはアップルのバグですか、私は何か間違ったことをしたことがわかりましたか？

Answer 1

参照日付が1970年1月1日の方法timeIntervalSinceDateが問題の原因です。ウィキペディアから

= 2038

1970 + 68

：

2038年問題

は、2038年問題は、時間の値がされたコンピューティングおよびデータストレージ 状況に問題があります格納されているか計算されており、この数値は1970年1月1日00:00:00（00:00:00 UTC）以降の 秒の数として解釈されます（「epo ch "）。このような の実装では、1月19日の03:14:07 UTCの後の時刻をエンコードすることはできません。これは、 "Y2K 問題"（「Millennium Bug」とも呼ばれます）と同様ですが、2桁1900年以降の年数を表す値 は、 2000年以降をエンコードできませんでした。ほとんどの32ビットUNIX系システムは、この「Unix時間」形式で時刻 を格納して操作するため、2038年の問題はアソシエーション別に「Unix Millennium Bug」と呼ばれる になることがあります。

記事本文：Year 2038 problem