Bilgisayar saati 1970'ten beri saniye sayıyor: 2038 sorunu ve artık saniyenin sonu

Terminale date +%s yazınca ekrana tek bir sayı geliyor. Ben bu yazıyı hazırlarken 1.792.761.102 çıktı. Bu, 1 Ocak 1970 gecesinden o ana kadar geçen saniye sayısı. Dosya tarihlerinden çerez sürelerine, günlük kayıtlarından sertifikalara kadar pek çok yerde zaman böyle tek bir tam sayı olarak tutuluyor. Bu sayının hikâyesinde şu sıralar iki tarih öne çıkıyor: 19 Ocak 2038'de 32 bitlik sayaçlar doluyor, 20 Mayıs 2027'den itibaren de dünya saati artık saniye eklemeyi bırakıyor. İkisi sık sık birbirine karıştırılıyor, oysa aynı sorun değiller.

Bir sayı nasıl takvim oldu?

POSIX tanımına göre Unix zamanı, "Epoch"tan bu yana geçen saniyeyi verir ve her günü tam 86.400 saniye sayar (Open Group, bölüm 4.16). Epoch, 1 Ocak 1970 00:00:00 UTC. Bu tarihin özel bir anlamı yok. Wikipedia, Unix mühendislerinin onu "çalışması kolay bir tarih" olduğu için seçtiğini aktarıyor. İlk sürümlerde durum farklıydı: sistem saniyenin altmışta birini sayan 32 bitlik bir sayaç kullanıyordu ve bu sayaç yaklaşık iki yıl üç ayı taşıyabiliyordu. Taşmayı önlemek için başlangıç tarihi kaydırıldı, 1971 ve 1972 de denendi, sonunda sayım tam saniyeye çevrildi.

$ date +%s                      # şimdiki zaman, saniye cinsinden
$ date -u -d @0                 # GNU date: sayıdan tarihe
Thu Jan  1 00:00:00 UTC 1970
$ date -u -d @-2147483648       # negatif sayı, 1970 öncesi
Fri Dec 13 20:45:52 UTC 1901

macOS ve BSD sistemlerinde -d @sayı yerine -r sayı kullanılıyor. Komutların çıktısını kendi makinemde çalıştırarak doğruladım.

O dönemin makinelerinde "sayı" kelimesi bugünkünden çok daha fiziksel bir şeydi: Panelde adres ve veri satırlarının ışıkları yanıp sönüyor, bir sayının genişliği bir sıra ışığın uzunluğuyla ölçülüyordu. Bana kalırsa 2038 sorununu anlamak için bu görüntü iyi bir başlangıç. Sayaç ne kadar geniş yapılırsa o kadar ileri sayıyor, ve bir noktada sıra bitiyor.

2038'de ne taşıyor?

Unix zamanını işaretli 32 bitlik bir tam sayıda tutarsanız tavan 2³¹ − 1, yani 2.147.483.647. Bu sayı 19 Ocak 2038'de 03:14:07 UTC'ye denk geliyor. Bir saniye sonra sayaç en küçük değere, −2³¹'e dönüyor ve onu tarih sanan bir program 13 Aralık 1901 20:45:52 UTC'yi görüyor (Wikipedia). Aynı davranışı birkaç satırda görmek mümkün:

import struct, datetime

t = 2**31                                   # 03:14:08 UTC, 19 Ocak 2038
taşmış = struct.unpack('<i', struct.pack('<I', t))[0]
print(taşmış)                               # -2147483648
print(datetime.datetime.fromtimestamp(taşmış, datetime.timezone.utc))
# 1901-12-13 20:45:52+00:00

Risk nerede, kimde değil?

Telefonların ve dizüstü bilgisayarların büyük bölümü 64 bitlik zamanla çalışıyor. Asıl zorluk uzun yıllar çalışan 32 bitlik gömülü sistemlerde: yönlendiriciler, kameralar, araç denetim birimleri. Wikipedia'nın derlemesine göre bu cihazlar tarih hesabı ya da günlük kaydı yaptıklarında risk taşıyor, güncellenmeleri de zor ya da imkânsız olabiliyor. Yalnızca iki an arasındaki farkı ölçen sistemlerde ciddi bir sorun beklenmiyor.

2038'i beklemek de gerekmiyor. 2006'da AOLserver, bir milyar saniye sonrasına ayarlanmış bir zaman aşımı yüzünden 13 Mayıs'ta, 01:27:28 UTC'den sonra gelen isteklerde taşmaya takıldı. Ayarı düşürmek sorunu çözdü. Aynı kaynakta bitiş tarihi 2038'i geçen sertifikaların da 32 bitlik sistemlerde doğrulama hatası verebildiği yazıyor. Buradan çıkardığım ders şu: İleri tarihli bir değer hesaplayan her kod (sertifika, çerez, abonelik süresi) 2038'e yaklaşmadan önce o sınıra çarpabilir.

Düzeltme: sayaç genişliyor

Çözümün özü basit: Sayacı 64 bite çıkarmak. 64 bitlik sistemlerin çoğunda zaten böyle. Wikipedia'nın sıraladığına göre Linux çekirdeği 5.6'dan (2020) itibaren 32 bitlik mimarilerde de 64 bitlik time_t kullanabiliyor, glibc ise 2.34'ten (Ağustos 2021) beri _TIME_BITS=64 tanımlanınca bunu açıyor. Gnulib yazışmalarında 32 bitlik hedeflerde _FILE_OFFSET_BITS=64 değerinin de birlikte verilmesi gerektiği not ediliyor. Kendi kodunuzda şuna bakabilirsiniz:

#include <stdio.h>
#include <time.h>

int main(void) {
    printf("time_t: %zu bayt\n", sizeof(time_t));
    return 0;
}

$ gcc -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 t.c -o t
$ ./t
time_t: 8 bayt

64 bitlik makinemde program bayraksız da 8 bayt veriyor. Bayraksız derlenen bir 32 bitlik hedefte çoğu zaman 4 bayt çıkar, sorun orada başlıyor. Zaman yalnızca time_t içinde de durmuyor: Dosya sistemleri, veritabanı sütunları ve ağ protokolleri kendi alanlarını taşıyor.

Sayaç artık saniyeyi hiç saymadı

Unix zamanı her günü 86.400 saniye sayıyor, oysa UTC'de arada 86.401 saniyelik günler oluyor. Artık saniye eklenince Unix sayısı kendini tekrar ediyor: 1483228800, hem 31 Aralık 2016 23:59:60'a hem 1 Ocak 2017 00:00:00'a karşılık gelebiliyor. Artık saniyeyi aşan iki zaman damgasının farkı da bir saniye eksik çıkıyor (Wikipedia).

$ date -u -d @1483228800
Sun Jan  1 00:00:00 UTC 2017    # GNU date ":60" anını göstermez

Bu tablo değişiyor. Ağırlıklar ve Ölçüler Genel Konferansı (CGPM) 2022'de UT1 ile UTC arasındaki farkın üst sınırının "2035'te ya da öncesinde" artırılmasına karar vermişti (Karar 4). 13-15 Ekim 2026'da toplanan 28. CGPM ise işi öne çekti. 5 numaralı karar, kesintisiz UTC'nin 20 Mayıs 2027'de yürürlüğe gireceğini ve |UT1 − UTC| farkının üst sınırının 3.600 saniye (1 saat) olacağını söylüyor. Kararın gerekçe bölümünde, hiç uygulanmamış bir "negatif artık saniye"nin yüksek risk taşıdığı da yazıyor. Haberi Euronews da aktardı.

İki konu neden karışıyor?

Bana kalırsa karışıklığın nedeni ikisinin de "zaman" etiketi taşıması. 2038 bir depolama sorunu: Sayı kaç bit? Artık saniye ise saatin tanımıyla ilgili: Bir gün kaç saniye? 64 bite geçen bir sistem artık saniyeyi hâlâ saymıyor, artık saniyeyi bırakan dünya da 32 bitlik bir sayacı genişletmiyor. Küçük bir ironi de var: Unix zamanı artık saniyeyi yok sayarak tasarlandı, UTC de yeni saniye eklemeyi bırakınca bu yok sayma 2027'den sonrası için yeni bir belirsizlik üretmeyecek. Bu bir çıkarım, kararın metninde yazmıyor. Geçmişte eklenmiş saniyeler ise tarihte duruyor, eski kayıtlardaki belirsizlik de duruyor.

Kodun ve bilgisayarların tarihiyle ilgileniyorsanız şu yazı da hoşunuza gidebilir:

Kaynaklar

1. Unix time, Wikipedia (erişim: 2026-10-23)
2. Year 2038 problem, Wikipedia (erişim: 2026-10-23)
3. The Open Group Base Specifications, 4.16 Seconds Since the Epoch (erişim: 2026-10-23)
4. PDP-11, Wikipedia (erişim: 2026-10-23)
5. BIPM, 28th CGPM (2026), Resolution 5: On the technical actions needed to ensure the continuity of UTC (erişim: 2026-10-23)
6. BIPM, 27th CGPM (2022), Resolution 4 (erişim: 2026-10-23)
7. Euronews, 16 Ekim 2026: küresel zaman kuralları değişiyor, artık saniye 2027'de bitiyor (erişim: 2026-10-23)
8. Gnulib: glibc 2.34 _TIME_BITS=64 desteği üzerine yazışma (erişim: 2026-10-23)

Kapak görseli: Jason Scott · CC BY 2.0. Şema: özgün grafik.