繼上個月的十二行代碼分分鐘讓瀏覽器崩潰iPhone重啟事件之后，近日又有網(wǎng)友爆出：如果把64位的iOS設(shè)備(iPhone、iPad、iPod touch)系統(tǒng)時間修改為1970年1月1日，設(shè)備重啟后將變磚。

　　也有人稱：即便是進DFU模式都無法刷機重啟，只能到售后去解決問題。

　　今天抱著No Try No High Give Me Five的心態(tài)把自己的iPhone(型號：5S)系統(tǒng)時間設(shè)置成了1970年1月1日：

　　當時的我心想：只要把時間設(shè)置成23點五十多分，只需十來分鐘就能恢復正常，想想都覺得自己機智得不要不要的，然后安心地重啟了設(shè)備。

　　重啟之后，設(shè)備和大多數(shù)人的一樣：變磚了，一直卡在開機的Logo界面，而且設(shè)備還比平時更燙。

　　原以為只有等十幾分鐘，系統(tǒng)日期轉(zhuǎn)為1970年1月2日的時候就能恢復，可是蘋果白屏持續(xù)了二十分鐘，然后又關(guān)機放了二十分鐘依舊不能開機!

　　終于，設(shè)備在系統(tǒng)時間為1970年1月2日零點三十多分的時候進入了正常界面，BTW沒想到的是輸入鎖屏密碼竟然有十來秒的延遲，然后設(shè)備又自動重啟了!然后就一直白屏、發(fā)燙直到?jīng)]電… 嗯，當時整個人的狀態(tài)是這樣的：

　　No Zuo No Die Why You Cry,You Try You Die Don't Ask Why.

　　蘋果客服給出了一個強制恢復方法：

　　使用這一方法時建議最好采用windows機器來進行操作。

　　到這一步時，選擇更新或者恢復均可。

　　接著iTunes將會下載1.8個G的iOS9.2.1系統(tǒng)文件，下載完成將進行軟件提取、恢復操作：

　　恢復階段時iTunes、蘋果均會顯示進度條：

　　之后只需耐心等待數(shù)十分鐘即可。

　　如果之前未進行數(shù)據(jù)備份，通過這種方法對iPhone進行恢復后原有數(shù)據(jù)將全部丟失!

　　那么是否還有其他方法呢?答案是有的。那就是：拆機并拆出電池，放置10分鐘后重新安裝。(這一方法未進行驗證，如不想數(shù)據(jù)丟失的小伙伴可嘗試一下)

　　為什么會有這個Bug?(下面答案內(nèi)容來自feomg@知乎)

　　iOS系統(tǒng)時間使用Unix時間戳(Unix epoch)表示(time_t數(shù)據(jù)類型)。在系統(tǒng)中，使用系統(tǒng)位數(shù)個二進制位儲存時間。Unix時間戳規(guī)定：UTC時區(qū)的1970年1月1日 0點0時0秒的值為0，以秒為單位，即每過一秒，二進制數(shù)字加1。

　　在32位系統(tǒng)中，time_t是長度為32位的，有符號整數(shù)(signed int)類型。首個二進制位是符號位，用來儲存正負。正數(shù)則為1970/1/1以后的時間，負數(shù)反之;其余的31位用來記數(shù)。當時間到達2038年1月19日 3時14分08秒時，數(shù)值位全部向前進1，導致符號位被置1，其余31位為0。介時，將出現(xiàn)『時間回歸』的情況，系統(tǒng)時間變?yōu)?901年12月13日 20時45分52秒，系統(tǒng)將會出現(xiàn)錯誤。

　　那么64位系統(tǒng)中又是怎樣的問題呢?我們說到了以UTC時區(qū)的1970年1月1日 0點0時0秒為界限，數(shù)值為0，時間正常流逝為正數(shù)，反之為負數(shù)。不過各位需要留意的是，時間受到時區(qū)的影響。

　　假設(shè)一種情況，我原來是北京時區(qū)，假設(shè)將時間設(shè)置到了1970年1月1日0點0時0秒，那么我將這個時間轉(zhuǎn)換為UTC時間，公式：北京時間= GMT+8 = UTC+8,那么UTC時間則為1969年12月31日16時0分0秒。這樣就會出現(xiàn)時間負值，即時間回歸bug觸發(fā)，系統(tǒng)啟動卡在Kernel階段，時間錯誤，無法繼續(xù)進行啟動。

　　蘋果是如何回應(yīng)的?

　　蘋果官方對這一事件做出了回應(yīng)，確認如果將系統(tǒng)時間手動設(shè)置為1970年5月或者更早，iPhone、iPad、iPod touch將會無法重啟。

　　蘋果稱會在未來的軟件更新中解決這個問題，但不清楚會在如今的iOS 9.2.2上直接OTA，還是得等下個月的iOS 9.3。

　　蘋果建議已經(jīng)變磚的用戶聯(lián)系蘋果售后，但是現(xiàn)在Apple Store里的很多員工都頭疼死了：因為不少人很好奇這個Bug，但舍不得拿自己的iPhone做試驗，就跑到蘋果店里把人家的展示用iPhone、iPad給玩死了……

　　蘋果的這一問題不禁讓人想起：linux 2.6.18-164以下版本內(nèi)核在處理閏秒事件的問題以及千年蟲(計算機2000年問題，縮寫為“Y2K”)

　　Linux內(nèi)核閏秒問題

　　這一問題發(fā)生在2012年7月，當時水木社區(qū)用戶稱：低內(nèi)核版Linux開啟NTP服務(wù)將會在本月遇到閏秒BUG，從而導致服務(wù)器重啟。該用戶表示：國際地球自轉(zhuǎn)和參考坐標系統(tǒng)服務(wù)(IERS)將在格林威治時間2012年6月30日**增加一閏秒。

　　由于Linux kernel和Posix關(guān)于NTP時間跳變的標準不同，將在2012年6月30日23:59:59跳變到2012年7月1日后引起ntpd進程鎖死，從而造成部分開啟ntp服務(wù)的linux系統(tǒng)重啟。Linux內(nèi)核在2.6.18-164.e15之后的版本中解決了這個問題。

　　格林威治時間對應(yīng)到北京時間即7月1日的7點59分59秒，中國也曾于這個時間全球同步進行閏秒調(diào)整，出現(xiàn)了7點59分60秒的特殊現(xiàn)象。

　　千年蟲問題

　　百科上的資料顯示：計算機2000年問題，又叫做“千年蟲”、“電腦千禧年千年蟲問題”或“千年危機”。縮寫為“Y2K”。是指在某些使用了計算機程序的智能系統(tǒng)(包括計算機系統(tǒng)、自動控制芯片等)中，由于其中的年份只使用兩位十進制數(shù)來表示，因此當系統(tǒng)進行(或涉及到)跨世紀的日期處理運算時(如多個日期之間的計算或比較等)，簡單來說,就是由于早期的計算機配置比較低，為了節(jié)省空間就把年份只用后兩位數(shù)表示，如1900就表示為00，這樣到新千年時便會出現(xiàn)問題了：電腦把2000年認為是1900年。就會出現(xiàn)錯誤的結(jié)果，進而引發(fā)各種各樣的系統(tǒng)功能紊亂甚至崩潰。因此從根本上說千年蟲是一種程序處理日期上的bug，而不是病毒。