Apakah Itu Cap Masa Unix?

Cap masa Unix ialah satu nombor tunggal: kiraan saat yang telah berlalu sejak epok Unix, yang ditakrifkan sebagai 00:00:00 UTC pada 1 Januari 1970. Itu sahaja. Tiada zon waktu, tiada rentetan tarikh, tiada nama bulan — hanya satu integer yang naik satu unit sesaat.

Oleh kerana epok itu tetap dan universal, cap masa seperti 1700000000 bermaksud detik yang sama tepat di mana-mana di Bumi. Pelayan di Tokyo dan komputer riba di Chicago kedua-duanya bersetuju bahawa ia merujuk kepada 14 November 2023 pada 22:13:20 UTC. Paparan tempatan berbeza mengikut zon waktu, tetapi nombor asasnya tidak pernah berubah.

Satu penyederhanaan yang disengajakan: Masa Unix mengabaikan saat lompat. Ia menganggap setiap hari tepat 86,400 saat panjang, yang tidak benar sepenuhnya dalam realiti astronomi tetapi memastikan aritmetik bersih. Lebih lanjut di bawah.

Mengapa Jurutera Menyukainya

Cap masa ada di mana-mana dalam perisian — masa pengubahsuaian fail, rekod pangkalan data, respons API, medan luput JWT, baris log — dan atas sebab yang baik:

• Ia adalah satu nilai tunggal. Satu integer menyimpan tarikh dan masa penuh. Tiada penghuraian, tiada kekaburan tentang MM/DD lawan DD/MM.
• Ia tidak terikat dengan zon waktu. Nombor itu sentiasa UTC. Anda tukar ke waktu tempatan hanya apabila anda menunjukkannya kepada manusia.
• Ia mudah dibandingkan dan diisih. Peristiwa mana yang berlaku dahulu? Integer yang lebih kecil. Tempoh antara dua peristiwa? Tolak sahaja; jawapannya dalam saat.
• Ia disimpan dengan padat. Satu integer 4 atau 8 bait berbanding rentetan berformat.

Inilah sebabnya begitu banyak infrastruktur menggunakan saat epok di bawah hud, walaupun antara muka menunjukkan 2026-07-23 yang mesra. Jika anda ingin bergerak antara dua perwakilan ini, penukar cap masa Unix melakukan terjemahan dalam kedua-dua arah.

Membaca Satu Cap Masa: Contoh Kerja

Ambil cap masa 1000000000 — yang terkenal, kerana ia melimpah di televisyen langsung di kalangan peminat Unix.

Untuk membacanya secara manual, anda bahagikan saat kepada unit yang lebih besar. Secara kasar, 1,000,000,000 saat adalah kira-kira 31.7 tahun (setahun adalah ~31,556,952 saat). Tambah itu ke epok 1970 dan anda sampai ke 2001. Detik tepatnya ialah 9 September 2001, 01:46:40 UTC.

Anda jarang melakukan aritmetik ini secara manual — setiap bahasa mempunyai fungsi terbina. Dalam Python:

```python from datetime import datetime, timezone datetime.fromtimestamp(1000000000, tz=timezone.utc)

2001-09-09 01:46:40+00:00

```

Perkara utama: penukaran sentiasa berlabuh ke UTC. Fungsi menukar kiraan saat mentah menjadi tarikh kalendar dengan berjalan ke hadapan dari epok. Jika anda mahukan waktu tempatan sebaliknya, anda gunakan offset zon waktu selepas penukaran UTC — cap masa itu sendiri tidak membawa maklumat zon.

Masalah Tahun 2038

Di sinilah cerita menjadi menarik — dan di mana kebanyakan sistem yang dibina dengan baik mempunyai jam yang berdetik di dalamnya.

Selama beberapa dekad, jenis piawai C yang digunakan untuk menyimpan masa Unix, time_t, biasanya adalah integer 32-bit bertanda. Integer 32-bit bertanda boleh mewakili nilai dari −2,147,483,648 hingga 2,147,483,647. Had atas itulah masalahnya.

Mengira saat dari epok 1970, nilai 2,147,483,647 dicapai pada 03:14:07 UTC pada 19 Januari 2038. Satu saat kemudian, pembilang perlu menjadi 2,147,483,648 — tetapi nombor itu tidak muat dalam integer 32-bit bertanda. Daripada terus naik, bit melimpah dan melilit kepada nilai paling negatif, −2,147,483,648.

Cap masa negatif ditafsirkan sebagai masa sebelum epok. Jadi jam tidak hanya berhenti — ia melompat ke belakang ke 13 Disember 1901. Mana-mana sistem yang mempercayai time_t 32-bitnya tiba-tiba percaya ia berada pada awal abad kedua puluh.

Ini sering dipanggil bug Y2K38 atau Bug Milenium Unix, dan dari segi struktur, ia adalah limpahan lebar tetap yang sama yang mendorong ketakutan Tahun 2000 — cuma lebih jauh dan berakar pada had integer binari dan bukannya tahun dua digit.

Di Mana Ia Benar-Benar Menggigit

Desktop dan pelayan 64-bit moden kebanyakannya telah diperbaiki tahun lalu. Risiko tertumpu di tempat yang sukar dikemas kini:

• Sistem terbenam dan industri. Penghala, pengawal, peranti perubatan, ECU automotif, dan perkakasan IoT yang dihantar dengan time_t 32-bit dan mungkin berjalan tanpa disentuh selama 20+ tahun. Banyak peranti yang digunakan hari ini masih akan berkhidmat pada 2038.
• Kod C warisan. Aplikasi yang dikompil terhadap takrifan time_t lama, terutamanya apabila jenis itu menyusup ke dalam format cakera atau protokol rangkaian.
• Pangkalan data dan sistem fail lama. Format storan yang membungkus cap masa ke dalam medan 32-bit. Sesetengah sistem lama sudah menunjukkan simptom apabila mengendalikan tarikh masa depan yang jauh — fikirkan gadai janji 20 tahun atau luput sijil yang mencapai selepas 2038.

Mod kegagalan tidak selalunya kemalangan dramatik. Kadang-kadang ia adalah tarikh yang dikira secara halus salah: token luput yang dibaca sebagai sah, susunan isih yang terbalik, kerja berjadual yang diaktifkan pada 1901.

Pembetulan: Masa 64-Bit

Penawarnya mudah pada prinsipnya — lebarkan time_t kepada 64 bit. Integer 64-bit bertanda boleh mengira saat jauh melampaui mana-mana ufuk praktikal: titik limpahan berada kira-kira 292 bilion tahun pada masa hadapan, dengan selesa melepasi jangka hayat Matahari.

Kebanyakan sistem operasi semasa telah pun membuat perpindahan ini. Linux 64-bit menggunakan time_t 64-bit; walaupun Linux 32-bit telah mendapat sokongan masa 64-bit dalam kernel dan glibc sejak beberapa tahun lalu. Bahagian yang sukar bukanlah pembetulan itu sendiri — ia adalah mencari dan membina semula setiap bahagian perisian tegar, setiap format tersimpan, dan setiap binari pihak ketiga yang masih menganggap 32 bit. Kerja audit itulah projek 2038 yang sebenar.

Bagaimana Saat Lompat Sesuai

Masa astronomi dan masa atom menyimpang sedikit, jadi UTC rasmi kadang-kadang menyelitkan saat lompat untuk memastikan jam sejajar dengan putaran Bumi. Masa Unix, dengan reka bentuk, berpura-pura ia tidak wujud — ia mengkodkan keras 86,400 saat sehari.

Apabila saat lompat berlaku, sistem biasanya "mengusap"nya — menyebarkan saat tambahan merentas tetingkap (Google mempopularkan usapan 24 jam) supaya tiada jam yang perlu menunjukkan 23:59:60 yang mustahil. Hasilnya: cap masa Unix kekal lancar dan monoton, dengan kos menjadi pecahan sesaat kecil dari UTC ketat semasa usapan. Untuk hampir semua perisian, ini sebenarnya keseimbangan yang anda mahu. Limpahan 2038 adalah masalah lebar integer; saat lompat adalah keanehan takrifan yang berasingan dan lebih kecil — jangan campurkan.

Pengambilan Utama

• Cap masa Unix adalah saat sejak 00:00:00 UTC pada 1 Januari 1970, mengabaikan saat lompat.
• Ia adalah integer tunggal yang tidak terikat dengan zon waktu — mudah disimpan, dibandingkan, dan diisih.
• Penukaran sentiasa relatif kepada UTC; waktu tempatan digunakan selepas itu.
• time_t 32-bit bertanda melimpah pada 03:14:07 UTC pada 19 Januari 2038, melilit kepada nilai negatif dan melompat ke 1901.
• Pembetulan adalah time_t 64-bit; usahanya adalah mengaudit sistem terbenam dan warisan.

Mahu melihatnya beraksi? Tampal mana-mana nilai epok ke dalam penukar cap masa Unix untuk membacanya sebagai tarikh manusia — atau pergi ke arah lain dan tukar tarikh kepada cap masanya.

Soalan Lazim

Adakah cap masa Unix dalam saat atau milisaat?

Masa Unix klasik adalah dalam saat. Walau bagaimanapun, JavaScript dan banyak API web menggunakan milisaat sejak epok, jadi nilai seperti 1700000000000 adalah 1,000× lebih besar. Petanda cepat: cap masa berasaskan saat untuk tarikh terkini mempunyai 10 digit; yang milisaat mempunyai 13. Jika ragu-ragu, periksa magnitud sebelum menukar.

Adakah masalah Tahun 2038 akan merosakkan telefon atau komputer riba saya?

Hampir pasti tidak. Sistem operasi 64-bit moden sudah menggunakan time_t 64-bit, yang menolak limpahan berbilion tahun ke hadapan. Pendedahan sebenar adalah pada peranti terbenam yang tahan lama dan perisian lama yang masih bergantung pada masa 32-bit dan mungkin tidak dikemas kini sebelum 2038.

Bolehkah cap masa Unix menjadi negatif?

Ya. Nilai negatif mewakili detik sebelum epok 1970 — contohnya, -1 ialah 31 Disember 1969, 23:59:59 UTC. Inilah yang dihasilkan oleh limpahan 32-bit pada 2038, itulah sebabnya jam kelihatan melompat kembali ke 1901.

Mengapa masa Unix mengabaikan saat lompat?

Untuk memastikan matematik mudah dan boleh diramal. Menganggap setiap hari sebagai tepat 86,400 saat bermakna tempoh hanyalah penolakan, dan cap masa kekal monoton. Ketidakpadanan kecil dengan UTC astronomi dikendalikan dengan "mengusap" saat lompat, yang hampir semua aplikasi lebih suka daripada berurusan dengan kes tepi 23:59:60.

Bagaimana saya menukar cap masa tanpa menulis kod?

Gunakan alat dalam talian. penukar cap masa Unix menerima nilai epok dan menunjukkan tarikh-masa UTC dan tempatan yang sepadan serta-merta, dan ia menukar tarikh kalendar kembali kepada cap masa.