2023年問題又叫unix千年臭蟲或y2k38錯誤。在時間值以帶符號的32位整數來儲存或計算的資料儲存情況下，這個錯誤就有可能引發問題。
可以用unix帶符號的32位整數時間格式來表示的最大時間是 2023年1月19日03:14:07utc（2038-01-19t03:14:07z），這是自 1970-01-01t00:00:00z 之後過了 2147483647 秒，值的邊界如下：
時間時間戳
二進位制字面量
1970-01-01t00:00:00z
000000000 00000000 00000000 00000000
2038-01-19t03:14:07z
2^31-1, 2147483647
01111111 11111111 11111111 11111111
測試**：
// 0
long a = 0;
// 2^31-1, 2147483647
long b = integer.max_value;
// 1970-01-01t00:00:00.000z
instant.ofepochsecond(a).atzone(zoneoffset.of("-00:00")).tolocaldatetime()
// 2038-01-19t03:14:07.000z
instant.ofepochsecond(b).atzone(zoneoffset.of("-00:00")).tolocaldatetime()
下面這個動畫顯示了2023年錯誤將如何重置日期：
[外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳(img-biypnceb-1612353563376)(
目前，2023年錯誤沒有什麼通行的解決方案。如果對用於儲存時間值的time_t資料型別的定義進行更改，依賴帶符號的32位time_t整數性質的應用程式就會出現一些**相容性問題。假設time_t的型別被更改為不帶符號的32位整數，那將加大最新的時間限制。但是，這會對由負整數表示的2023年之前的日期造成混亂。
使用64位架構的作業系統和程式使用64位time_t整數。使用帶符號的64位值可以將日期延長至今後的2920億年。
已有人提出了許多建議，包括以帶符號的64位整數來儲存自某個時間點（2023年1月1日或2023年1月1日）以來的毫秒/微秒，以獲得至少30萬年的時間範圍。其他建議包括用新的庫重新編譯程式，等等。這方面的工作正在開展之中；據專家們聲稱，2023年問題解決起來應該不難。
unix時間 - 維基百科
unix時間戳和普通時間戳 轉換
unix時間戳是從1970年1月1日 utc gmt的午夜 開始所經過的秒數，不考慮閏秒，以秒為單位 new date gettime 獲得的是以毫秒為單位的 js中獲取unix時間戳的方式 math.round new date gettime 1000 gettime 返回數值的單位是毫秒 un...
Unix時間戳轉化時間
因為專案中經常用到unix時間戳的轉化，今天就總結一下 php中 這種方式在php程式中完成轉換，優點是無論是不是資料庫中查詢獲得的資料都能轉換，轉換範圍不受限制，缺點是占用php解析器的解析時間，速度相對慢。用函式 date 一般形式 date y m d h i s unix時間 php中將正常...
Unix時間戳轉換 python
coding utf 8 import time deftimestamp datetime value format y m d h m s value為傳入的值為時間戳 整形 如 1332888820 value time.localtime value 經過localtime轉換後變成 tim...