Pergi ke kandungan

Pepijat tahun 2038

Daripada Wikipedia, ensiklopedia bebas.
Visual animasi pepijat sedang berlaku. Ralat limpahan akan berlaku pada 03:14:08 UTC pada 19 Januari 2038.

Pepijat tahun 2038 (juga dikenali sebagai Y2038,[1] Y2K38, superbug Y2K38, atau Epochalypse[2][3]) ialah masalah pengkomputeran masa yang menyebabkan sesetengah sistem komputer tidak dapat mewakili masa selepas 03:14:07 UTC pada 19 Januari 2038.

Masalah ini wujud dalam sistem yang mengukur Waktu Unix—bilangan saat yang telah berlalu sejak epok Unix (00:00:00 UTC pada 1 Januari 1970)—dan menyimpannya dalam integer 32-bit ditanda. Apabila nilai maksimum jenis data dilampaui, integer tersebut akan melimpah ke nilai minimumnya, yang diinterpretasikan oleh sistem sebagai masa lalu. Masalah ini menyerupai pepijat tahun 2000, yang disebabkan oleh penggunaan perwakilan perpuluhan (asas-10) lebar tetap, manakala pepijat tahun 2038 disebabkan oleh penggunaan perwakilan perduaan (asas-2) lebar tetap.

Sistem komputer yang menggunakan masa untuk pengiraan kritikal mungkin menghadapi ralat membawa maut jika pepijat tahun 2038 tidak ditangani. Sesetengah aplikasi yang menggunakan tarikh masa hadapan telah pun menghadapi pepijat ini.[4][5] Sistem yang paling rentan ialah sistem yang jarang atau tidak pernah dikemas kini, seperti sistem warisan dan sistem terbenam. Sistem moden dan kemas kini perisian menangani masalah ini dengan menggunakan integer 64-bit ditanda, yang mengambil masa 292 bilion tahun untuk melimpah—kira-kira 21 kali ganda anggaran umur alam semesta semasa.[6]

Punca

[sunting | sunting sumber]

Banyak sistem komputer mengukur masa dan tarikh menggunakan Waktu Unix, piawaian antarabangsa untuk penjagaan masa digital. Waktu Unix ditakrifkan sebagai bilangan saat yang telah berlalu, mengabaikan saat lompat, sejak 00:00:00 UTC pada 1 Januari 1970, yang dikenali sebagai Epok Unix.

Waktu Unix secara sejarahnya telah dikodkan sebagai integer 32-bit ditanda, jenis data yang terdiri daripada 32 digit perduaan (bit) yang mewakili nilai integer, dengan 'ditanda' bermakna nombor tersebut boleh mewakili kedua-dua nombor positif dan negatif, serta sifar; dan biasanya disimpan dalam format pelengkap dua.[a] Oleh itu, integer 32-bit ditanda hanya boleh mewakili nilai integer daripada −(231) hingga 231 − 1 merangkumi semua. Kesannya, jika integer 32-bit ditanda digunakan untuk menyimpan Waktu Unix, masa terkini yang boleh disimpan ialah 231 − 1 (2,147,483,647) [b] saat selepas epok, iaitu 03:14:07 UTC pada 19 Januari 2038.[7] Sistem yang cuba menambah nilai ini dengan satu saat lagi kepada 231 saat selepas epok (03:14:08) akan mengalami limpahan integer, secara tidak sengaja menterbalikkan bit tanda untuk menunjukkan nombor negatif. Ini mengubah nilai integer kepada −(231), atau 231 saat sebelum epok dan bukannya selepas, yang diinterpretasikan oleh sistem sebagai 20:45:52 UTC pada 13 Disember 1901. Dari sini, sistem akan terus mengira naik, menuju ke sifar, dan kemudian naik menerusi nombor integer positif semula. Disebabkan banyak sistem komputer menggunakan pengiraan masa untuk menjalankan fungsi kritikal, pepijat ini boleh menimbulkan masalah serius.

Sistem rentan

[sunting | sunting sumber]

Mana-mana sistem yang menggunakan struktur data dengan perwakilan masa 32-bit ditanda mempunyai risiko sedia ada untuk gagal. Senarai penuh struktur data ini hampir mustahil untuk diterbitkan, tetapi terdapat struktur data terkenal yang mempunyai masalah Waktu Unix:

  • Sistem fail yang menggunakan 32 bit untuk mewakili masa dalam inode, seperti ext2, ext3, dan reiserFS.
  • Pangkalan data dengan medan masa 32-bit.
  • Bahasa pertanyaan pangkalan data (seperti SQL) yang mempunyai arahan seperti UNIX_TIMESTAMP().
  • Banyak peranti Android 32-bit pada Android 4 atau lebih awal, termasuk ZTE Blade,[8] Google Nexus 7[9] dan tablet Android Toshiba 2012.[10]
  • Mac era OS X PowerPC akan mengalami jam sistem tersangkut pada masa peralihan setakat Mac OS X Tiger.[11]
  • Peranti 32-bit iOS setakat iPhone 5 pada kira-kira iOS 9 tidak akan dapat dinyahkunci atau secara konsisten memasuki mod pengecasan, dan jam skrin kunci tidak akan kelihatan.[12]
  • Setakat kira-kira Windows 10 versi 22H2, jika peranti x86 (32-bit) belum dihidupkan pada titik peralihan, tetapi dihidupkan selepas peralihan, jam sistem boleh melompat ke hadapan ke 12 April 2160, dan pilihan tarikh dalam menu tetapan utama Windows 10 tidak menunjukkan sebarang nombor yang boleh dipilih.[13]
  • Perisian yang dibina dengan Visual Studio mempunyai format _gmtime32 (yang berfungsi sebagai pemetaan versi 32-bit time_t) beralih pada 19 Januari 2038 00:00:00. Perisian yang dibina dengan versi Visual Studio sebelum 2005 diketahui mempunyai _gmtime yang sepadan dengan _gmtime32, dan padanan tersebut boleh dipaksa apabila membina dengan versi 32-bit Visual Studio menerusi Visual Studio 2019 dengan menetapkan _USE_32BIT_TIME_T.[14]

Sistem terbenam

[sunting | sunting sumber]

Sistem terbenam yang menggunakan tarikh sama ada untuk pengiraan atau pembalakan diagnostik berkemungkinan besar terjejas oleh masalah Y2038.[1] Walaupun terdapat kemas kini generasi 18–24 bulan Hukum Moore dalam teknologi sistem komputer, sistem terbenam direka bentuk untuk bertahan sepanjang hayat mesin yang menjadi komponennya. Boleh difahami bahawa sesetengah sistem ini mungkin masih digunakan pada tahun 2038. Mungkin sukar atau, dalam sesetengah kes, mustahil untuk menaik taraf perisian yang menjalankan sistem ini, yang akhirnya memerlukan penggantian jika had 32-bit perlu diperbetulkan.

Banyak sistem pengangkutan, daripada penerbangan hingga automotif, menggunakan sistem terbenam secara meluas. Dalam sistem automotif, ini mungkin merangkumi sistem pembrekan анти-kunci (ABS), kawalan kestabilan elektronik (ESC/ESP), kawalan cengkaman (TCS), dan pemacu empat roda automatik; pesawat mungkin menggunakan sistem panduan inersia dan penerima GPS.[c]

Satu lagi kegunaan utama sistem terbenam adalah dalam peranti komunikasi, termasuk telefon bimbit dan peralatan berdaya Internet, contohnya penghala, titik capaian tanpa wayar, kamera IP, yang bergantung pada menyimpan masa dan tarikh yang tepat dan semakin banyak berasaskan sistem pengendalian seakan Unix.

Walau bagaimanapun, ini tidak bermakna semua sistem terbenam akan terjejas oleh masalah Y2038, kerana banyak sistem sedemikian tidak memerlukan capaian kepada tarikh. Bagi yang menggunakannya, sistem yang hanya menjejak perbezaan antara masa/tarikh dan bukannya masa/tarikh mutlak, mengikut sifat pengiraan tersebut, tidak akan mengalami masalah besar. Ini merupakan masalah untuk diagnostik automotif berasaskan piawaian berkanun seperti CARB (Lembaga Sumber Udara California).[15]

Masalah awal

[sunting | sunting sumber]

Pada Mei 2006, laporan muncul mengenai kemunculan awal masalah Y2038 dalam perisian AOLserver. Perisian ini direka bentuk dengan penyelesaian sementara untuk mengendalikan permintaan pangkalan data yang sepatutnya "tidak pernah" tamat masa. Daripada mengendalikan kes khas ini secara khusus, reka bentuk awal hanya menetapkan tarikh tamat masa arbitrari pada masa hadapan dengan konfigurasi lalai yang menetapkan bahawa permintaan sepatutnya tamat masa selepas maksimum satu bilion saat. Walau bagaimanapun, satu bilion saat sebelum tarikh had 2038 ialah 01:27:28 UTC pada 13 Mei 2006, jadi permintaan yang dihantar selepas masa ini akan menghasilkan tarikh tamat masa yang melampaui tarikh had. Ini menyebabkan pengiraan tamat masa melimpah dan mengembalikan tarikh yang sebenarnya pada masa lalu, menyebabkan perisian terhenti. Apabila masalah ini ditemui, pengendali AOLServer perlu mengedit fail konfigurasi dan menetapkan tamat masa kepada nilai yang lebih rendah.[4][5]

Banyak jenis sijil CA tandatangan sendiri yang dijana pada sistem 32-bit boleh mempunyai tarikh tamat tempoh yang sangat panjang yang melampaui titik peralihan, yang akan menyebabkannya tidak berfungsi dengan betul, menjejaskan pengesahan HTTPS pada perkhidmatan (sebagai contoh VPN) dan tapak web yang menggunakannya.[16]

Fungsi antiperisian tebusan MS Filtering Engine Update bagi pemasangan Microsoft Exchange Server terhenti pada 1 Januari 2022 selepas satu kemas kini. Fungsi tersebut memetakan nombor UpdateVersion yang diproses (yang menggunakan format YY-MM-DD-n 9 atau 10 digit) kepada nombor cap masa Waktu Unix walaupun masa kedua-duanya sangat berbeza, jadi apabila enjin menerima kemas kini 220101001 (22-01-01 v001), yang difahaminya sebagai 2201010001 dengan ekstra sifar berhampiran penghujung, ia cuba memetakkannya kepada nombor Waktu Unix 32-bit dan gagal kerana lebih tinggi daripada 2147483647.[17] Pelayan Exchange yang terjejas gagal berfungsi melainkan mereka mematikan fungsi antiperisian tebusan, dan penyelesaian automatik telah diterbitkan pada 5 Januari 2022.[perlu rujukan]

Dalam Oracle Access Management versi 10.1.4.3 untuk Windows, komponen Konsol Identiti menetapkan kuki yang mengandungi keutamaan antaramuka pengguna dengan tamat tempoh 500,000,000 saat pada masa hadapan (kira-kira 15 tahun, 312 hari). Bermula kira-kira 02:20:48 UTC pada 17 Mac 2022, tarikh tamat tempoh ini melebihi 19 Januari 2038 dan menyebabkan ia mencetuskan pengecualian untuk aktiviti carian tertentu kerana panggilan gmtime_r() tidak dapat menukar nombor yang disediakan kepada tarikh untuk ditulis pada kuki.[18]

Penyelesaian

[sunting | sunting sumber]

Tiada penyelesaian sejagat untuk pepijat tahun 2038. Sebagai contoh, dalam bahasa C, sebarang perubahan pada takrifan jenis data time_t akan mengakibatkan masalah keserasian kod dalam mana-mana aplikasi yang perwakilan tarikh dan masanya bergantung pada sifat integer 32-bit ditanda time_t. Mengubah time_t kepada integer 32-bit tidak ditanda, yang akan melanjutkan julat kepada 2106[19] (khususnya, 06:28:15 UTC pada Ahad, 7 Februari 2106), akan menjejaskan program yang menyimpan, mendapatkan semula, atau memanipulasi tarikh sebelum tahun 1970 secara negatif, kerana tarikh tersebut diwakili oleh nombor negatif. Meningkatkan saiz jenis time_t kepada 64 bit dalam sistem sedia ada akan menyebabkan perubahan tidak serasi pada susun atur struktur dan antaramuka biner fungsi.

Banyak sistem pengendalian yang direka untuk berjalan pada peranti keras 64-bit sudah pun menggunakan integer time_t 64-bit ditanda. Menggunakan nilai 64-bit ditanda memperkenalkan tarikh balutan baharu yang lebih daripada dua puluh kali ganda lebih besar daripada anggaran umur alam semesta: kira-kira 292 bilion tahun dari sekarang.[20] Walau bagaimanapun, perisian pada sistem pengendalian 64-bit masih boleh menyebabkan masalah dengan menggunakan integer 32-bit untuk mengendalikan cap masa.[21] Keupayaan untuk membuat pengiraan pada tarikh terhad disebabkan oleh hakikat bahawa tm_year menggunakan nilai integer 32-bit ditanda bermula pada tahun 1900 untuk tahun tersebut. Ini mengehadkan tahun kepada maksimum 2,147,485,547 (2,147,483,647 + 1900).[22]

Cadangan alternatif telah dibuat (sesetengah daripadanya sudah pun digunakan), seperti menyimpan sama ada milisaat atau mikrosaat sejak epok (biasanya sama ada 1 Januari 1970 atau 1 Januari 2000) dalam integer 64-bit ditanda, menyediakan julat minimum 292,000 tahun pada resolusi mikrosaat.[23][24] Khususnya, penggunaan integer 64-bit ditanda oleh Java dan JavaScript untuk mewakili cap masa mutlak sebagai "milisaat sejak 1 Januari 1970" akan berfungsi dengan betul untuk 292 juta tahun akan datang. Cadangan lain untuk perwakilan masa baharu menyediakan ketepatan, julat, dan saiz yang berbeza (hampir sentiasa lebih luas daripada 32 bit), serta menyelesaikan masalah berkaitan yang lain, seperti pengendalian saat lompat. Khususnya, TAI64[25] ialah pelaksanaan piawaian Masa Antarabangsa Atom (TAI), iaitu piawaian masa nyata antarabangsa semasa untuk mendefinisikan saat dan kerangka rujukan.[perlu rujukan]

Penyelesaian yang dilaksanakan

[sunting | sunting sumber]
  • Bermula dengan Ruby versi 1.9.2 (dikeluarkan pada 18 Ogos 2010), pepijat dengan tahun 2038 telah diperbaiki,[26] dengan menyimpan masa dalam integer 64-bit bertanda pada sistem dengan 32-bit time_t.[27]
  • Bermula dengan NetBSD versi 6.0 (dikeluarkan pada Oktober 2012), sistem pengendalian NetBSD menggunakan 64-bit time_t untuk kedua-dua seni bina 32-bit dan 64-bit. Aplikasi yang dikompilasi untuk keluaran NetBSD yang lebih lama dengan 32-bit time_t disokong melalui lapisan keserasian binar, tetapi aplikasi lama tersebut masih akan mengalami masalah Y2038.[28]
  • OpenBSD sejak versi 5.5, dikeluarkan pada Mei 2014, juga menggunakan 64-bit time_t untuk kedua-dua seni bina 32-bit dan 64-bit. Berbanding dengan NetBSD, tiada lapisan keserasian binar. Oleh itu, aplikasi yang menjagakan 32-bit time_t dan aplikasi yang menggunakan apa-apa selain daripada time_t untuk menyimpan nilai masa mungkin terganggu.[29]
  • Linux pada asalnya menggunakan 64-bit time_t untuk seni bina 64-bit sahaja; Antara muka perduaan aplikasi (ABI) 32-bit tulen tidak diubah berikutan keserasian kebelakangan.[30] Bermula dengan versi Sejarah versi kor Linux 5.6 pada tahun 2020, 64-bit time_t turut disokong pada seni bina 32-bit. Ini dilakukan terutamanya demi sistem Linux terbenam.[31]
  • Perpustakaan C GNU sejak versi 2.34 (dikeluarkan Ogos 2021), menambah sokongan untuk menggunakan 64-bit time_t pada platform 32-bit dengan versi Linux yang sesuai. Sokongan ini boleh diaktifkan dengan mendefinisikan makro praprosesor _TIME_BITS kepada 64 apabila mengkompilasi kod sumber.[32]
  • FreeBSD menggunakan 64-bit time_t untuk semua seni bina 32-bit dan 64-bit kecuali 32-bit i386[d], yang sebaliknya menggunakan 32-bit bertanda time_t.[33]
  • ABI x32 untuk Linux (yang mendefinisikan persekitaran untuk program dengan alamat 32-bit, tetapi menjalankan pemproses dalam mod 64-bit) menggunakan 64-bit time_t. Memandangkan ia merupakan persekitaran baharu, tiada keperluan untuk langkah berjaga-jaga keserasian khas.[30]
  • Sistem Fail Rangkaian versi 4 telah mendefinisikan medan masanya sebagai struct nfstime4 {int64_t seconds; uint32_t nseconds;} sejak Disember 2000.[34] Versi 3 menyokong nilai 32-bit tidak bertanda sebagai struct nfstime3 {uint32 seconds; uint32 nseconds;};.[35] Nilai yang lebih besar daripada sifar untuk medan saat menunjukkan tarikh selepas jam 0, 1 Januari 1970. Nilai kurang daripada sifar untuk medan saat menunjukkan tarikh sebelum jam 0, 1 Januari 1970. Dalam kedua-dua kes, medan nseconds (nanosaat) hendaklah ditambah pada medan saat untuk mewakilkan masa akhir.
  • Sistem fail ext4, apabila digunakan dengan saiz inod lebih besar daripada 128 bait, mempunyai medan 32-bit tambahan setiap cap masa, yang mana 30 bit digunakan untuk bahagian nanosaat cap masa, dan 2 bit lagi digunakan untuk memanjangkan julat cap masa sehingga tahun 2446.[36]
  • Sistem fail XFS, bermula dengan Linux 5.10, mempunyai ciri pilihan "cap masa besar" yang memanjangkan julat cap masa sehingga tahun 2486.[37]
  • Walaupun API asli OpenVMS boleh menyokong cap masa sehingga 31 Julai 31086,[38] pustaka masa-larian C (CRTL) menggunakan integer 32-bit untuk time_t.[39] Sebagai sebahagian daripada kerja pematuhan Y2K yang dijalankan pada tahun 1998, CRTL telah diubah suai untuk menggunakan integer 32-bit tidak bertanda untuk mewakilkan masa; memanjangkan julat time_t sehingga 7 Februari 2106.[40]
  • Setakat MySQL 8.0.28, dikeluarkan pada Januari 2022, fungsi FROM_UNIXTIME(), UNIX_TIMESTAMP(), dan CONVERT_TZ() mengendalikan nilai 64-bit pada platform yang menyokongnya. Ini termasuk versi 64-bit Linux, macOS, dan Windows.[41][42] Dalam versi lebih lama, fungsi terbina dalam seperti UNIX_TIMESTAMP() akan mengembalikan 0 selepas 03:14:07 UTC pada 19 Januari 2038.[43]
  • Setakat MariaDB 11.5.1, dikeluarkan pada Mei 2024, jenis data TIMESTAMP dan fungsi FROM_UNIXTIME(), UNIX_TIMESTAMP(), serta CONVERT_TZ() mengendalikan nilai 32-bit tidak bertanda pada versi 64-bit Linux, macOS, dan Windows.[44] Ini memanjangkan julat kepada 2106-02-07 06:28:15 dan membenarkan pengguna menyimpan nilai cap masa sedemikian dalam jadual tanpa mengubah susun atur penstoran sekali gus kekal serasi sepenuhnya dengan data pengguna sedia ada.
  • Bermula dengan Visual C++ 2005, CRT menggunakan 64-bit time_t melainkan makro praprosesor _USE_32BIT_TIME_T didefinisikan.[45] Walau bagaimanapun, API Windows sendiri tidak terjejas oleh pepijat tahun 2038, kerana Microsoft Windows menjejak masa secara dalaman sebagai bilangan selang 100-nanosaat sejak 1 Januari 1601 dalam integer 64-bit bertanda, yang tidak akan melimpah sehingga tahun Masalah pemformatan dan penyimpanan masa.[46]
  • Pepijat Jam sistem tersangkut OS X rollover telah diperbaiki setakat Mac OS X El Capitan.[perlu rujukan]
  • DOSBox-X mengalih keluar kebergantungan pada makro Int32x32To64 untuk pengiraan masa dalam versi 2025.02.01.[47]
  • Bagi peranti Windows yang jamnya terlanjur ke hadapan, beberapa alatan perisian untuk menyunting tetapan sistem atau menyelaraskan dengan pelayan masa wujud untuk meredakan sebarang kesan.[perlu rujukan]
  • Panduan sintaks Microsoft untuk Visual Studio telah tidak menggalakkan penggunaan _USE_32BIT_TIME_T, dan ia tidak dibenarkan apabila membina dengan versi 64-bit Visual Studio.[14]
  • Walaupun usia versi Oracle Access Manager berkenaan sudah lama (18 Jun 2009), Oracle telah mengeluarkan tampalan 33983548 pada 6 April 2022. Versi Oracle Access Manager yang lebih baharu tidak diketahui terjejas oleh masalah ini.[perlu rujukan]

Lihat juga

[sunting | sunting sumber]

Nota

[sunting | sunting sumber]
  1. ↑ Melainkan dinyatakan sebaliknya, semua nombor yang disediakan dalam artikel ini telah diterbitkan menggunakan pelengkap dua untuk aritmetik integer ditanda.
  2. ↑ 2,147,483,647 ialah nombor perdana Mersenne berganda
  3. ↑ GPS mengalami masalah limpahan pembilang masa sendiri yang dikenali sebagai Rollover Nombor Minggu GPS.
  4. ↑ Bermula dengan FreeBSD 15.0, sokongan untuk seni bina CPU 32-bit termasuk i386 telah digugurkan. Walau bagaimanapun, seni bina 32-bit armv7 telah dikecualikan daripada ini.

Rujukan

[sunting | sunting sumber]
  1. 1 2 Gibbs, Samuel (17 Disember 2014). "Is the Year 2038 problem the new Y2K bug?". The Guardian. Diarkibkan daripada yang asal pada 25 Januari 2022. Dicapai pada 11 Oktober 2018.
  2. ↑ Bergmann, Arnd (6 Februari 2020). "The end of an Era". Linaro. Diarkibkan daripada yang asal pada 7 Februari 2020. Dicapai pada 13 September 2020.
  3. ↑ Wagenseil, Paul (28 Julai 2017). "Digital 'Epochalypse' Could Bring World to Grinding Halt". Tom's Guide. Diarkibkan daripada yang asal pada 29 November 2021. Dicapai pada 13 September 2020.
  4. 1 2 "The Future Lies Ahead". 28 Jun 2006. Diarkibkan daripada yang asal pada 28 November 2006. Dicapai pada 19 November 2006.
  5. 1 2 Weird "memory leak" problem in AOLserver 3.4.2/3.x Diarkibkan 4 Januari 2010 di Wayback Machine 12 May 2006
  6. ↑ 263 saat ÷ 60 saat/minit ÷ 60 minit/jam ÷ 24 jam/hari ÷ (146097 hari/400 tahun =) 365.2425 hari/tahun Gregory [≈ 292.277 bilion tahun (Gregory)] ÷ 13.79 bilion tahun ≈ 21.19 kali ganda anggaran umur alam semesta selepas tengah malam UTC pada 1 Januari 1970, mengabaikan saat lompat.
  7. ↑ Diomidis Spinellis (2006). Code quality: the open source perspective. Effective software development series in Safari Books Online (ed. illustrated). Adobe Press. m/s. 49. ISBN 978-0-321-16607-4.
  8. ↑ "ZTE Blade running Android 2.2 has 2038 problems". Diarkibkan daripada yang asal pada 19 Mei 2022. Dicapai pada 20 November 2018.
  9. ↑ Larry Seltzer (19 Januari 2013). "25 Years From Today: A Time for Bugs". InformationWeek. Diarkibkan daripada yang asal pada 26 Ogos 2025. Dicapai pada 16 Ogos 2025.
  10. ↑ "Toshiba TOSHIBA AT300" (PDF). 2012. Diarkibkan (PDF) daripada yang asal pada 4 September 2025. Dicapai pada 16 Ogos 2025.
  11. ↑ "The year 2038 problem". Interlinked. Diarkibkan daripada yang asal pada 16 Julai 2014. Dicapai pada 16 Ogos 2025.
  12. ↑ Ternary (10 Disember 2015). "The iPhone Apocalypse: January 19, 2038". MacRumors. Dicapai pada 17 Ogos 2025.
  13. ↑ Sayan Sen (6 Mac 2024). "Remember Y2K? Windows 95, 98, 2000-era app surprisingly stands tall against Y2K38 superbug". Neowin. Diarkibkan daripada yang asal pada 3 September 2025. Dicapai pada 19 Ogos 2025.
  14. 1 2 "gmtime, _gmtime32, _gmtime64". Microsoft Learn. 2 Mac 2024. Diarkibkan daripada yang asal pada 8 Disember 2024. Dicapai pada 11 September 2025.
  15. ↑ "ARB Test Methods / Procedures". ARB.ca.gov. Lembaga Sumber Udara California. Diarkibkan daripada yang asal pada 18 November 2016. Dicapai pada 12 September 2013.
  16. ↑ Thomas Claburn (9 Februari 2025). "Curious tale of broken VPNs, the Year 2038, and certs that expired 100 years ago". The Register. Diarkibkan daripada yang asal pada 1 Ogos 2025. Dicapai pada 17 Ogos 2025.
  17. ↑ Dean Howell (1 Januari 2022). "Y2K22 bug: Microsoft rings in the new year by breaking Exchange servers all around the world". Neowin. Diarkibkan daripada yang asal pada 24 Ogos 2025. Dicapai pada 19 Ogos 2025.
  18. ↑ "Oracle Access Manager". Oracle Communities. Oracle Corporation. 24 Mac 2022. Dicapai pada 25 Februari 2023.
  19. ↑ "DRAFT: Y2038 Proofness Design". Diarkibkan daripada yang asal pada 21 September 2019. Dicapai pada 25 Mei 2024.
  20. ↑ Endrestøl, Trond (10 Mac 2015). "When does the 64-bit Unix time_t really end?". Ximalas. Diarkibkan daripada yang asal pada 23 September 2022. Dicapai pada 24 September 2022.
  21. ↑ "Today is Y2K38 commemoration day T-13". 19 Januari 2025.{{cite web}}: CS1 maint: url-status (link)
  22. ↑ Felts, Bob (17 April 2010). "The End of Time". Stablecross.com. Diarkibkan daripada yang asal pada 11 Oktober 2012. Dicapai pada 19 Mac 2012.
  23. ↑ "Unununium Time". Diarkibkan daripada yang asal pada 8 April 2006. Dicapai pada 19 November 2006.
  24. ↑ Sun Microsystems. "Java API documentation for System.currentTimeMillis()". Diarkibkan daripada yang asal pada 30 September 2017. Dicapai pada 29 September 2017.
  25. ↑ "TAI64". Diarkibkan daripada yang asal pada 26 September 2012. Dicapai pada 4 September 2012.
  26. ↑ "Ruby 1.9.2 is released". 18 Ogos 2010. Diarkibkan daripada yang asal pada 8 April 2022. Dicapai pada 1 April 2022.
  27. ↑ "time.c: use 64bit arithmetic even on platforms with 32bit VALUE". GitHub. Diarkibkan daripada yang asal pada 3 November 2023. Dicapai pada 3 November 2023.
  28. ↑ "Announcing NetBSD 6.0". 17 Oktober 2012. Diarkibkan daripada yang asal pada 15 Januari 2016. Dicapai pada 18 Januari 2016.
  29. ↑ "OpenBSD 5.5 released (May 1, 2014)". 1 Mei 2014. Diarkibkan daripada yang asal pada 22 Disember 2015. Dicapai pada 18 Januari 2016.
  30. 1 2 Jonathan Corbet (14 Ogos 2013). "Pondering 2038". LWN.net. Diarkibkan daripada yang asal pada 4 Mac 2016. Dicapai pada 9 Mac 2016.
  31. ↑ "LKML: Arnd Bergmann: [GIT PULL] y2038: core, driver and file system changes". lkml.org. Diarkibkan daripada yang asal pada 14 Februari 2020. Dicapai pada 30 Januari 2020.
  32. ↑ O'Donell, Carlos (2 Ogos 2021). "The GNU C Library version 2.34 is now available". Sourceware. Diarkibkan daripada yang asal pada 30 April 2024. Dicapai pada 30 April 2024.
  33. ↑ "arch". www.freebsd.org. Diarkibkan daripada yang asal pada 26 September 2018. Dicapai pada 26 September 2018.
  34. ↑ Haynes, Thomas; Noveck, David, penyunting (Mac 2015). "Structured Data Types". Network File System (NFS) Version 4 Protocol. sec. 2.2. doi:10.17487/RFC7530. RFC 7530.
  35. ↑ Staubach, Peter; Pawlowski, Brian; Callaghan, Brent (Jun 1995). "NFS Version 3 Protocol Specification". Diarkibkan daripada yang asal pada 15 Mei 2024. Dicapai pada 25 Mei 2024.
  36. ↑ "ext4 Data Structures and Algorithms". Diarkibkan daripada yang asal pada 13 September 2022. Dicapai pada 13 September 2022.
  37. ↑ Michael Larabel (15 Oktober 2020). "XFS File-System With Linux 5.10 Punts Year 2038 Problem To The Year 2486". Phoronix. Diarkibkan daripada yang asal pada 13 September 2022. Dicapai pada 13 September 2022.
  38. ↑ "Why is Wednesday, November 17, 1858 the base time for OpenVMS (VAX VMS)?". Universiti Stanford. 24 Julai 1997. Diarkibkan daripada yang asal pada 24 Julai 1997. Dicapai pada 8 Januari 2020.
  39. ↑ "VSI C Run-Time Library Reference Manual for OpenVMS Systems" (PDF). VSI. November 2020. Diarkibkan daripada yang asal (PDF) pada 17 April 2021. Dicapai pada 17 April 2021.
  40. ↑ "OpenVMS and the year 2038". HP. Diarkibkan daripada yang asal pada 17 April 2021. Dicapai pada 17 April 2021.
  41. ↑ "What Is New in MySQL 8.0". dev.mysql.com. Diarkibkan daripada yang asal pada 13 November 2021. Dicapai pada 13 November 2021.
  42. ↑ "Changes in MySQL 8.0.28 (2022-01-18, General Availability)". dev.mysql.com. Diarkibkan daripada yang asal pada 8 Disember 2023. Dicapai pada 14 Mei 2024.
  43. ↑ "MySQL Bugs: #12654: 64-bit unix timestamp is not supported in MySQL functions". bugs.mysql.com. Diarkibkan daripada yang asal pada 29 Mac 2017. Dicapai pada 28 Mac 2017.
  44. ↑ "MariaDB 11.5.1 Release Notes". MariaDB KnowledgeBase. Diarkibkan daripada yang asal pada 7 September 2024. Dicapai pada 6 September 2024.
  45. ↑ "Microsoft C/C++ change history 2003 - 2015". learn.microsoft.com (dalam bahasa Inggeris AS). 25 Mei 2023. Dicapai pada 13 Ogos 2024.
  46. ↑ "About Time - Win32 apps". learn.microsoft.com (dalam bahasa Inggeris AS). 7 Januari 2021. Dicapai pada 13 Ogos 2024.
  47. ↑ Jon Campbell. "DOSBox-X 2025.02.01 Release Notes". Diarkibkan daripada yang asal pada 23 April 2025. Dicapai pada 19 Ogos 2025.

Pautan luar

[sunting | sunting sumber]

Templat:Masalah berkaitan tahun Templat:Risiko malapetaka global

Diambil daripada "https://ms.wikipedia.org/w/index.php?title=Pepijat_tahun_2038&oldid=6950592"