Y10K (Yıl 10.000 Problemi) ve Yıl 2038 Problemi Nedir ?

tarafından
Y10K (Yıl 10.000 Problemi) ve Yıl 2038 Problemi Nedir ?

10.000 yıl problemi (aynı zamanda Y10K problemi veya on yıllık millenyum böceği olarak da bilinir) beş basamaklı yıllar ifade etmesi gerektiğinde ortaya çıkacak tüm potansiyel zaman biçimlendirme ve depolama hatalarının sınıfıdır. 2038 yılı problemi, 2038 yılında bazı POSIX zaman gösterimini kullanan 32-bit sistemlerin çökmesine yol açacak bir yazılım hatasıdır.

Y10K problemi ve yıl 2038 problemi

Y10K Problemi Nedir ?

10.000 yılına kadar kim öle kim kala diyebilirsiniz. Fakat beş basamaklı bir yıl şimdiden ileriye dönük birçok analiz programı (örneğin, nükleer atıkların uzun vadeli olarak ele alınmasına ilişkin teklifleri inceleyen yazılım) için bir sorun teşkil etmektedir. 10.000 yılda bazı programların tarih ile ilgili 4 haneli değerler kullanmasından dolayı çıkacak sorundur.

Y10K Problemi Yaşayacak Programlar

Microsoft Excel

Microsoft Excel elektronik tablo programında, en azından 31 Aralık 1899’dan bu yana gün sayısı olarak tarihleri ​​depolayan Office 2013 sürümünden görülebilir (1. gün 1900-01-01); Benzer şekilde, Microsoft Access mağazaları da 30 Aralık 1899’dan bu yana geçen gün sayısıdır (1. gün 1899-12-31). Her iki başvuruda da, 2958465 tarih değeri doğru “31 Aralık 9999” olarak biçimlendirilir, ancak “1 Ocak 10000” beklenen tarihe geçmek için buna 1 eklenmesi biçimlendirme hatasına neden olur; Örneğin, Excel’de hücrede # karakterlik bir dizi olarak gösterilecektir. Excel ayrıca, yıl 9999’u aşarsa, “12/12/2007” gibi tarih biçimli dizeleri otomatik olarak tarihlere dönüştüremez; “12/12/9999”, bir hücreye girildiğinde otomatik olarak bir tarihe dönüştürülür, ancak “12/12/10000” değildir.

SAP NetWeaver

SAP NetWeaver, tarih değişkenlerini 8 karakterli dizeler olarak işler (YYYY/MM/DD).

OpenOffice Calc

Açık kaynak OpenOffice.org Calc programı, 9999 yılı aşan tarihleri, beş basamaklı yıllarla doğru şekilde gösterebiliyor, ancak en azından 2.4 sürümüyle 32.768 Yılı sorununa düşüyor: “31 Aralık 32.767”, uygun bir şekilde alabileceği en yüksek tarih. 32767 veya 215 – 1, 16 bitlik işaretli bir tamsayı kullanılarak gösterilebilecek en yüksek pozitif sayıdır, bu değere bir tane eklemek, taşmaya neden olur ve Calc, yılı büyük bir negatif sayı olarak yorumlar, “1 Ocak −32,768 “.

GNU Fortran

GNU Fortran derleyicisi, g77, bu derleyici paketi ile içsel işlevler kullanırken çalışma ortamı sınırlarında 10.000 (Y10K) yıl sınırlarını referans alıyor. Sorun, basitçe “Tarih bilgisine dayanan çoğu iade ya da hesaplama değerleri, yıl için sadece 4 rakamı desteklediğinden 10.000 (Y10K) Yılı sorunlarına açıktır.” Tüm içsel işlevlerde önerilen hata kipi, “Bu içkeni kullanan programlar, Yıl 10000 (Y10K) uyumlu olmayabilir. Örneğin, bu tür programlara sarılmak için tarih belirtilebilir.

Python

Python’un datetime modülü açıkça yalnızca bir ila dört basamaklı tarihleri ​​destekler. Daha sonraki veya daha önceki bir yılı içeren bir tarih kullanılması, bir ValueError’un ortaya çıkmasına neden olur.

PHP

PHP’nin DateTime sınıfı, örn. Yeni DateTime (…).

Yılların depolanan değerlerinden önemli basamakların çıkarıldığı 2000 yılı sorunundan farklı olarak, 10.000 yılındaki sorunu düzeltmek için eski kayıtların güncellenmesini gerektirmez (zaten Y2K uyumlu olduğu varsayılmaktadır), çünkü dört önemli basamak da mevcuttur. Yalnızca ondalık basamakta kayıt depolamasının beş veya daha fazla basamak depolayabilmesini gerektirir.

Bununla birlikte, sözcük sıralamayı kullanan kayıt kümelerinde olası bir sorun vardır. Örneğin, 10.000–19.999 aralığında tarihlerin gösterimi, 9999 yılından sonra değil, 1000-1999 aralığındaki tarihlerle iç içe geçmiş gibi görünecektir.

Bir kuruluş yazı yazma geleneğini beş basamakla desteklemeye çalışıyor, böylece 2019 yılı “02019” olarak yazılacak. Bu, 10.000 Yıl sorununu önleyecektir, ancak “100.000 Yıl sorununa” duyarlı olacaktır.

Internet Kermit Servis Daemon (IKSD), Veritabanı Kayıt Formatında yıl için beş basamaklı bir alan kullanır: “Tarih alanı alanları, 1810 alanı içinde Y10K için ayrılmış öncü boşluk ile sağa ayarlanır”

ISO 8601, yılların dört haneli yazılacağını, ancak bilgi alışverişinde bulunan taraflar arasında önceden anlaşmaya varılarak beş veya daha fazla haneye uzatılmasına izin verdiğini belirtir.

Year 2038 (2038 Yılı Problemi Nedir ?)

Hata, sistem zamanını 1 Ocak 1970 tarihinden beri saniye bazında hesaplayan ve 32-bitlik UNIX ve türevi sistemlerde 19 Ocak 2038 Salı günü saat 03:14:07’de sayacın başa dönmesiyle sistem tarihinin 13 Aralık 1901 20:45:52’yi göstermesiyle ortaya çıkacaktır.

Son yıllarda bazı çözüm yöntemleri geliştirilse de hiçbiri basit ve uygulanabilir olamamıştır. Ancak 64 bit’li sistemlere geçişin 2038 yılına kadar tamamlanacağı ve böylece hatanın kendiliğinden ortadan kalkacağı düşünülmektedir.