2038 Yılı Problemi
Millenyum problemi olarak atlattığımız 2000 sendromundan sonra bizi bekleyen diğer bir tehdit Yıl 2038 problemi. Şaka değil gerçek! 32 bit mimarili Unix ve türevi sistemlerin tarih kısıtı yüzünden 2038 senesinde sistemler çökme tehlikesi altında. Unix tabanlı sistemlerde tarih saniye cinsinden hesaplanmakta. Hal böyle olunca 32 bit tam sayı (integer) kapasitesi bizi ancak 19 Ocak 2038 senesine kadar taşımakta. Saatlerimiz 03:14:07’ü gösterdiğinde Unix tabanlı sistemler tarihi tekrardan başa saracak programlar şuanki hali ile hata vermeye başlayacak. 64 bit işletim sistemlerini ise Allah uzun ömürler versin ne diyelim 🙂
Neleri Etkileyecek?
- Unix ve türevi işletim sistemlerinde çalışan Internet siteleri
Eski ve süregelen legacy uygulamaları
Gömülü (embedded) sistemleri
İngilizce Geniş Bilgi ; http://en.wikipedia.org/wiki/Year_2038_problem
Basit bir Perl komut satırı ile sisteminizin 2038 yılına nasıl tepki vereceğini inceleyebilirsiniz…
perl -e ‘use POSIX; $ENV{‘TZ’} = “GMT”; for ($clock = 2147483641; $clock < 2147483651; $clock++) {print ctime($clock); }’
perl -e ‘use POSIX; $ENV{‘TZ’} = “GMT”; for ($clock = 2147483641; $clock < 2147483651; $clock++) {print ctime($clock); }’
Yukarıdaki komutu MS Windows üzerinde Linux uygulamalarını çalıştırmak ve derlemek için kullandığım Cygwin ve bir Debian GNU/Linux sistemlerde denediğimde aşağıdaki çıktıyı elde ediyorum:
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
MS Windows için derlenmiş Perl’i kullanarak Windows 2000 Server komut satırında şu şekilde denediğimde ise:
perl -e “use POSIX; $ENV{‘TZ’} = ‘GMT’; for ($clock = 2147483641; $clock < 2147483651; $clock++) {print ctime($clock); }”
Şöyle bir çıktı elde ediyorum:
Tue Jan 19 05:14:01 2038
Tue Jan 19 05:14:02 2038
Tue Jan 19 05:14:03 2038
Tue Jan 19 05:14:04 2038
Tue Jan 19 05:14:05 2038
Tue Jan 19 05:14:06 2038
Tue Jan 19 05:14:07 2038
Tue Jan 19 05:14:02 2038
Tue Jan 19 05:14:03 2038
Tue Jan 19 05:14:04 2038
Tue Jan 19 05:14:05 2038
Tue Jan 19 05:14:06 2038
Tue Jan 19 05:14:07 2038
Görülen o ki 2038 yılı ile ilgili sorun devam ediyor. Uygulamaların bir kısmının 64 bitlik bir time_t kullanarak derlendiğinde sorunun bir kısmının giderilebileceği düşünülürse de 32 bit kullanarak tarih depolayan veritabanı sistemlerine dikkat etmekte fayda var!
