Yıl 2038 problemi [kapalı]

2038 Yılı konusunun çok sorunlu olma olasılığı nedir ?

Bu problemi, 2038’den sonraki bazı uzun vadeli kriptografik sertifikalarda işlemesi gereken gömülü bir Linux sisteminde karşılaştım, bu yüzden bunun benzerliğinin uygulama alanınıza bağlı olduğunu söyleyebilirim.

Çoğu sistem 2038'den önce iyi hazır olmak zorunda olsa da, bugün kendinizi geleceğe dönük tarihleri ​​hesaplamakla bulursanız, bir sorununuz olabilir.

Bunun önemli bir sorun olacağını düşünüyorum, 1999 / 2000'deki Y2K sorunlarından çok daha tehlikeli çünkü etkilenen kod genellikle daha düşük seviyedeydi (bu CTIME) ve zamanın bu şekilde depolandığı yerleri tespit etmek daha zor.

Meseleleri daha da karmaşık hale getirmek için, Y2K'nın nemli bir kalamar olarak algılanması olaya kadarki olaydaki soruna dikkat çekmeyi zorlaştıracaktır.

Kültürel referanslar:

Cory Doctorow, açık lisanslar altında kısa öykü komisyonculuğu / yayıncılığı için yeni bir model deniyordu ve bunlardan biri için Epoch'da zekice yaptığı 2038 tema önerdim: http://craphound.com/?p=2337

Birkaç yıl önce, 30 yıllık kredilerde hesaplama yapan ipotek programları gibi alanlarda zaten sorunların olduğu rapor edildi: 2008 + 30 = 2038.

64 bit işletim sistemi 2037 problemiyle nihayetinde alakasız. (CTIME, 2037'den 2038'e yakın biter).

Sorun, işletim sisteminin bit derinliği değil, işletim sisteminin nasıl zaman depoladığıdır. Veya veritabanı sütunu zaman depolamayı nasıl seçer? Veya bu dizin hizmetleri zaman sözdizimi özniteliği arka ucunda depo zamanını nasıl kullanır?

Bu, insanların düşündüğünden çok daha büyük bir problem, çünkü 32 bit zaman sayacını kullanmak çok endemik ve yaygın.

Zaman depolayan her vakanın tekrar ziyaret edilmesi ve tüm API'lerin güncellenmesi ve onu kullanan tüm araçların güncellenmesi gerekir.

Yazılan ham veriler yerine insan tarafından okunabilir bir zaman biçiminde zaman ayarlamanıza izin veren soyutlama katmanları kolaylaştırır, ancak bu yalnızca bir durumdur.

Bunun çoğu insanın düşündüğünden daha büyük bir anlaşma olacağını düşünüyorum.

Bu benim görüşüme göre, ancak bu sorun 32 bitlik bir sayaç sorunundan kaynaklanıyor, bugün çoğu işletim sistemi 64 bitlik (en az 64 bitlik bilgisayarlarda) zamanı ele alacak şekilde güncellendi. 2038'den önceki zaman, 2020 diyelim. Dolayısıyla, yalnızca 2038'de 2020'den yazılım çalıştırmaya devam edecekseniz sorun yaşayabilirsiniz.
Büyük olasılıkla neredeyse her durumda bir sorun olmayacaktır. Umuyorum.

O kadar da önemli değil.

Yazılım ve donanım tedarikçilerinin ürünlerini satmaları için "Y2K uyumlu" olarak sertifikalandırması gereken ilk Y2K hava saldırısı sırasında (PC Bağlantısı üzerindeki ağ kablolarını Y2K uyumlu olduğunu hatırlıyorum) pek çok şirket her şeyin ayrıntılı denetimlerini yaptı. , gelecekte saatler ayarlayarak ve test ederek.

Testin maliyeti çok yüksek olduğu için, hemen hemen her zaman 1/1/99 (bazı geliştiricilerin 99'u bir hapishane olarak kullanmış olabilir), 12/31/99, 1/1 / 00, 2000, 1/19/38 ve diğer birçoklarının atılımı. Sıkıcı bir liste için buraya bakın .

Bu nedenle, 1999'da etrafta olan önemli bir yazılımın 2038 hataya sahip olmayacağına inanıyorum, ancak o zamandan beri cahil programcılar tarafından yazılmış yeni yazılımlar olabilir. Tüm Y2K debacle programcıları genel olarak tarih kodlama konularının çok daha fazla farkına vardıklarından, Y2K'nin (kendi başına bir anticlimax olan) olduğu kadar büyük bir etki yaratması muhtemel değildir.

O zaman hala çalışan 32 bit sistemler bir problem olacaktır.

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

int main() {
  time_t t = (time_t)(1L << (sizeof(time_t)*8 - 9));
  printf("%d\n", sizeof(time_t));
}

9 yerine 1 olmalıdır ancak ctime daha büyük tarihlerle başa çıkamaz:

8 - Sun Jun 13 07:26:08 1141709097

Sistemim (elbette 64 bit) zamanım 1 milyon yıl daha bile çalışabiliyor. Çözüm, sistemleri 64 bit olarak güncellemektir.

Program, programın üstesinden gelemeyebileceği yönündedir. Özellikle eski, uygun ve bakımı yapılmamış. Devs gerçekleri takip etmek için kullanılır:

• int32 bit (aslında diğerleri arasında 64 bit sistemlerde 32 bit olarak korunurlar çünkü her zaman 32 bit olduklarını varsaydılar)
• Çoğu tür (örneğin time_t) güvenle üzerine dökülebilirint

Popüler FLOSS yazılımında her iki şey de muhtemelen 'birçok göz' incelemesinden geçemez. Daha az popüler ve özellikli olduğunda, büyük ölçüde yazara bağlı olacaktır.

Özgür * nix dünyasında 2038 “farkedilmez” hale gelirken “uygun” platformlarda (yani, çok sayıda uygun yazılım içerenler) sorun beklemekteyim - özellikle de bazı parçaların bakımı yapılmayacaksa.

Y2K gibi bir şey varsa, bazı insanlar zaten etkilenmiş ve yazılımları değiştiriyor, ancak çoğu geliştirici 2030'larda bir zamana kadar, muhtemelen 2035'te bir süre öncesine kadar görmezden gelecektir. K & R C'yi bilmek ve henüz çok yaşlı olmamak birdenbire çok fazla parayla para kazanabilecek. Gerçek geçiş henüz yapılmayan, muhtemelen o kadar önemli olmayan pek çok şey gösterecektir.

Y2K problemi dört yerine yılı temsil eden iki tüzüktü.

Pek çok sistemin 2000'den 1900'den yalnızca '00'ı depoladığı için ayırt etmenin bir yolu yoktu.

Hemen hemen tüm sistemlerde ya yıl depolamak için 4 karakter ya da bir çeşit kütüphane kullanılıyor.

Öyleyse herkes 10000 yılı (Y10K) için endişelensinler. İşletim sistemi ve Kütüphane yazarları hariç ...