2038 Problemi: Bilgisayarların Saati 12 Yıl Sonra Duracak mı?

19 Ocak 2038, saat 06:14:07 (Türkiye saati). O saniyeden bir sonraki anda dünyadaki milyonlarca cihazın saati 2038'i göstermeyi bırakıp 13 Aralık 1901'e dönebilir. Bu bir bilim kurgu senaryosu değil; 2038 problemi, bilgisayarların zamanı nasıl saydığından doğan ve takvime tarihi çoktan yazılmış gerçek bir yazılım hatası. Üstelik bazı sistemler bu hatayla bugünden karşılaşıyor.

Kısaca:

• Birçok sistem zamanı "1 Ocak 1970'ten bu yana geçen saniye" olarak, 32 bitlik işaretli bir sayıda tutar.
• Bu sayı en fazla 2.147.483.647 olabilir; o değere 19 Ocak 2038 03:14:07 UTC'de ulaşılır.
• Bir saniye sonra sayı taşar, eksiye döner ve tarih 13 Aralık 1901'i gösterir.
• Modern 64 bit sistemler büyük ölçüde güvende; asıl risk gömülü cihazlar, eski veritabanı alanları ve 2038 sonrasını bugünden hesaplayan yazılımlarda.

Bilgisayarlar zamanı nasıl sayar?

Bilgisayarlar "30 Eylül 2026, 14:00" gibi bir tarihi doğrudan saklamaz. Unix ve ondan türeyen sistemler (Linux, macOS, Android, sunucuların büyük kısmı) zamanı tek bir sayı olarak tutar: 1 Ocak 1970 00:00:00 UTC'den bu yana geçen saniye sayısı. Bu başlangıç anına Unix epoch, sayının kendisine de Unix zaman damgası (timestamp) denir.

Örneğin bu yazının yayınlandığı günün başlangıcı, yani 30 Eylül 2026 00:00 UTC, Unix zamanında 1790726400 sayısıdır. Tarih, saat ve saat dilimi hesapları hep bu sayının üzerinden yapılır. Yöntem basit, hızlı ve evrenseldir; tek sorun, sayının saklandığı kutunun boyutudur.

Neden tam olarak 19 Ocak 2038?

C dilinde zamanı tutan time_t türü, uzun yıllar boyunca birçok sistemde 32 bitlik işaretli tam sayı olarak tanımlandı. 32 bitin bir biti işaret (artı/eksi) için kullanıldığından, bu kutuya sığabilecek en büyük sayı 2³¹ − 1, yani 2.147.483.647'dir.

1970'ten itibaren 2.147.483.647 saniye saydığınızda vardığınız an şudur: 19 Ocak 2038, 03:14:07 UTC. Türkiye saatiyle 06:14:07. Bugünden bakınca 12 yıldan az bir süre.

Sonraki saniyede sayı bir artmak ister ama kutu doludur. Kilometre sayacı 999.999'dan 000.000'a dönen eski bir araba gibi, sayı taşar (overflow) ve en küçük değere, −2.147.483.648'e atlar. Sistem bu negatif sayıyı "1970'ten önceki saniyeler" olarak okur ve tarih bir anda 13 Aralık 1901, 20:45:52 UTC'ye döner.

Kendi bilgisayarınızda görebilirsiniz

Bu hatayı görmek için özel bir donanım gerekmiyor. Python yüklüyse aşağıdaki birkaç satır, sınırın tam olarak nerede olduğunu ve taşmanın ne yaptığını gösterir:

import ctypes
from datetime import datetime, timedelta, timezone

epoch = datetime(1970, 1, 1, tzinfo=timezone.utc)

son_saniye = 2**31 - 1
print(epoch + timedelta(seconds=son_saniye))  # 2038-01-19 03:14:07+00:00

tasmis = ctypes.c_int32(son_saniye + 1).value  # 32 bitlik kutuya bir saniye daha
print(tasmis)                                  # -2147483648
print(epoch + timedelta(seconds=tasmis))       # 1901-12-13 20:45:52+00:00

ctypes.c_int32, sayıyı 32 bitlik bir kutuya zorla sığdırır. Sonuç, 2038'de eski sistemlerin içinde tam olarak olacak şeydir.

Y2K'den farkı ne?

2000 yılına girerken yaşanan Y2K endişesi, yılların iki haneyle (99) saklanmasından doğuyordu. 00, 2000 yerine 1900 olarak okunabilirdi. Dünya bu sorun için yıllarca hazırlandı ve büyük ölçüde sorunsuz atlatıldı. Bu başarı, "abartılmış bir panikti" algısını da beraberinde getirdi.

2038 problemi iki açıdan daha sinsi:

• Metinde değil, sayının içinde. Y2K'de tarihleri gözle görüp aratabiliyordunuz. 2038'de sorun, derlenmiş kodun ve veri türlerinin içinde gizli; kaynak kodda "2038" diye bir ifade geçmez.
• Gömülü cihazlarda yaşıyor. Sorunlu sistemlerin önemli kısmı bir bilgisayar değil; araçlardaki kontrol üniteleri, endüstriyel cihazlar, kameralar, modemler ve akıllı ev ürünleri. Bunların çoğu 10-20 yıl sahada kalır ve hiç güncelleme almaz.

Bu hatanın bir provası zaten yaşandı: GPS

Sayı taşmasının gerçek hayatta neye benzediğini görmek için 2038'i beklemek gerekmiyor. GPS uyduları, yayınladıkları navigasyon mesajında hafta numarasını yalnızca 10 bitle taşır. 10 bitle en fazla 1024 hafta sayılabilir; yani sayaç yaklaşık 19,7 yılda bir sıfırlanır.

Bu sıfırlanma son olarak 6 Nisan 2019'da yaşandı. Hazırlıksız alıcılar tarihi 1024 hafta geriye, 1999 Ağustos'una attı. Resmî GPS kaynaklarına göre bazı cihazlar o tarihte, bazıları ise aylar önce ya da sonra hatalı çalışmaya başladı ve yazılım/firmware güncellemesiyle düzeltildi. 2038 problemi aynı olgunun çok daha yaygın bir sürümü.

2038 sorunu bugünden nasıl ortaya çıkabilir?

"12 yıl var" demek rahatlatıcı gelebilir ama bir yazılımın 2038'le karşılaşması için o yılı beklemesi gerekmez. Geleceğe dönük tarih hesaplayan her sistem sınıra bugünden dokunur:

• Uzun vadeli sözleşmeler: 15 yıllık bir kredi, sigorta poliçesi ya da kira planı, vade tarihini 2038'in ötesine yerleştirir.
• Sertifikalar ve lisanslar: Uzun süreli geçerlilik tarihi verilen sertifika veya lisans anahtarları.
• Zamanlanmış görevler ve önbellekler: "Hiç sona erme" demek için çok ileri bir tarih seçen kodlar.
• Veritabanı alanları: MySQL'in resmi dokümantasyonuna göre TIMESTAMP veri türünün aralığı 1970-01-01 00:00:01 UTC ile 2038-01-19 03:14:07 UTC arasıdır. Bu türde saklanan bir bitiş tarihi, 2038 sonrasını tutamaz.

Kısacası sorun "2038'de gelecek" bir şey değil; bazı sistemler için şimdiden içeride.

Kimler risk altında, kimler güvende?

İyi haber şu: yazılım dünyası bu sorunu uzun zamandır biliyor ve önemli adımlar atıldı.

Burada kritik bir ayrıntı var: çekirdeği güncellemek tek başına yetmiyor. Linux 5.6 duyurusunda da belirtildiği gibi, kullanıcı alanındaki tüm yazılımların 64 bit time_t ile yeniden derlenmesi gerekiyor. Yani eski bir programı yeni bir sistemde çalıştırmak, onu otomatik olarak güvenli yapmıyor.

Geliştiriciler bugün ne yapmalı?

Yeni bir proje başlatıyorsanız 2038'e karşı korunmak çoğu zaman birkaç doğru tercihten ibaret:

1. Zamanı 32 bitlik bir tam sayıya sıkıştırmayın. Java'da (int) (System.currentTimeMillis() / 1000) gibi bir dönüşüm, 64 bitlik güvenli değeri kendi elinizle 32 bite indirir. long ya da java.time.Instant kullanın.
2. Veritabanında doğru türü seçin. MySQL'de 2038 sonrasını tutması gereken alanlar için TIMESTAMP yerine DATETIME düşünün. PostgreSQL'in timestamp türleri ise binlerce yıllık bir aralığı zaten kapsar.
3. Dosya ve ağ formatlarını kontrol edin. Zaman damgasını 4 baytlık bir alana yazan protokoller ve ikili dosya formatları, uygulamanız 64 bit olsa bile sınırı geri getirir.
4. Testlere 2038 sonrası tarihler ekleyin. Sistem saatini ileri alarak veya test verisine 2040 gibi tarihler koyarak sorunları erkenden görün.
5. Cihaz alımlarında sorun. Uzun ömürlü donanım (IoT, endüstriyel kontrol, araç içi sistem) seçerken üreticiye 2038 uyumluluğunu sorun.

Sıkça sorulan sorular

2038 problemi benim telefonumu ya da bilgisayarımı etkiler mi?

Büyük ihtimalle hayır. Günümüzdeki telefonlar ve bilgisayarlar 64 bit işlemci ve işletim sistemi kullanır; bunlarda zaman 64 bitle tutulur. Risk, eski 32 bit cihazlarda ve güncellenmeyen gömülü sistemlerdedir.

64 bit zaman ne zamana kadar yeter?

64 bitlik işaretli bir saniye sayacı yaklaşık 292 milyar yıl yeter. Bu, evrenin bugünkü yaşının yaklaşık 20 katıdır. Pratikte sorun tamamen ortadan kalkar.

2038 problemi Y2K gibi abartılmış bir korku mu?

Y2K sorunsuz geçti çünkü dünya yıllarca hazırlandı. 2038 için de hazırlık sürüyor ve modern sistemler büyük ölçüde güvende. Ama güncellenemeyen gömülü cihazlar ve eski veri formatları nedeniyle, hiçbir şey yapılmazsa gerçek arızalar yaşanması kaçınılmaz.

Neden sayaç 1970'ten başlıyor?

Unix işletim sistemi 1970'lerin başında geliştirildi ve geliştiriciler yakın, yuvarlak bir başlangıç noktası seçti. 1 Ocak 1970 00:00:00 UTC bu yüzden bilgisayar dünyasının "sıfır anı" oldu.

2038 problemi, yazılımda verilen küçük bir kararın (bir sayının kaç bitle tutulacağı) onlarca yıl sonra nasıl büyüyebileceğini gösteren en güzel örneklerden biri. Sistemlerinizi uzun ömürlü ve geleceğe dayanıklı kurmak istiyorsanız kurumsal yazılım geliştirme sayfamızdan bize ulaşabilirsiniz.

Kaynaklar