Tam Sürümünü Görmek İçin : Year 2038 unix time bug - y2k38 - research paper
konu üzerine yazmıs olduğum bir research paper.
yorumlarınızı düşüncelerinizi bekliyorum.
http://mail.baskent.edu.tr/~20194562/y2k38.txt
şu anki hali bir ön çalışma. anlam ve yazım hataları bulunmakta. düzeltilecektir..
2038'de biz de bugunun cobol programcilarina donecegimiz icin sorunu fazla kurcalamamakta fayda var. Eger 2038'de "bizim isimiz artik bitti" diye dusunurken bir anda zengin olmak istiyorsak :)
Konuyla ilgili birsey demek istiyorum. Uygulama yazilimlari artik verilerini buyuk oranda veritabanlarinda sakliyor ve veritabanlari ise isletim sistemlerinden bagimsiz kendi tarih/saat bilgilerini tutuyorlar. Veritabanlari ise tarih/saat bilgisini tutmak icin farkli secenekler sunuyorlar.
Ornegin MySQL kullanicilari, 2038'de omru bitecek olan TIMESTAMP veya 9999 yilina kadar sorunsuz calisacak olan DATETIME seceneklerinden uygun olanini secebiliyorlar.
Isletim sisteminde Y2K38 sorunu olmasi, uygulama yazilimlarini dogrudan baglamadigi icin tedbirli programcilar bu sorunu yasamaya bilir. Veya isletim sistemlerinde bu durum duzeltilmis olsa bile, uygulama katmaninda gerekli onlemler alinmadigi surece yine benzer sorunlar yasanabilir.
merhaba,
şu varki işletim sistemlerinde sorun sadece basit bir tarih sorunu değil:
mesela bir örnek:
linux'te process zamanlaması yapan schudeler her process icin bir timeval tutar ki buda long inttir. şimdi dusunelelim. tarih 2038 19 february oldugunda , 18'inde acmıs oldugunuz bir veritabanı programının processi, bahsettigimiz tarihe geldiginde soyle bir sorun cıkacaktir..
schudeler , processlere cpu time dagitirken bakacaktir ki veritabanı programı processi 18 january 2038'de açılmış ama o anki zaman 1901'li 1969'lu veya 1970'li bir zamani gostermektedir! Bu durumda buyuk ihtimal schudeler birsey yapamayacak isletim sistemi gocecek ve veritabani programlarınin da burda hic bir etkisi kalmayacaktir..
isletim sistemlerinde tarih sorunun usermod programlarda buna benzer bircok etkisi vardirki bu konuda arastırıyorum. bırakın yukardaki ornegi ben bu tarih geldiginde jiffy variablenın bile arttıralamayacagina olanak veriyiyorum (bu variable programmable timer device'dan gelen her IRQ'da artar ve bir bottom half sisteme yeni tickin bildirilmesi icin sıraya eklenir.)
Yazida belirttigin konulara katiliyorum. Dikkat cekmek istedigim nokta, bu sorunun 2005 veya 2035 yilinda cozulmesinin cok fazla seyi degistirmeyebilecegi, uygulama yazilimlari icin de ayni hassasiyet gosterilmedigi surece sorunun devam edecegi idi.
evet senın dediginde dogru. zaten benım bu makalayi yazmamdaki amac insanların bilinclenmesi. bu bilinclenme sayesinde coderlar daha saglikli kod yazabilirler. 2038 sorununu duymamıs olan bir coderdan , 2038-uyumlu kod yazılması beklenemez..
ellerine saglik raist:super:
saol abi daha gelistircem bakalım... hatalar var yenı eklemeler yapcam. iyi birseyler olması icin calisiyorum...
:)
bu arada linux ortamında calisan fakat koskoca yazıyı okuyamam diyenler icin:
sadece su perl dosyasını veyada C dosyasını calistirin sisteminizde:
test.pl
#!/usr/local/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
print ctime($clock);
}
# Correct output is the following:
#
# 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 <-- Last second in 32-bit Unix systems
# Tue Jan 19 03:14:08 2038
# Tue Jan 19 03:14:09 2038
# Tue Jan 19 03:14:10 2038
y2k38.c
/*
y2k38 - 2038 unix bug test program
Hüseyin Uslu - raistlinthewiz@hotmail.com
*/
#include <time.h>
int main(void)
{
long clock;
for (clock=2147483641;clock<2147483651;clock++)
{
printf("%s\n",ctime(&clock));
}
return 1;
}
Huseyin simdidden dunya butcesine milyon$ lar kazandirdi :super:
Ama benim simdi merak ettigim konu ise, embedded sistemler ne olacak?
Zira 10 larca yil calismak uzere tasarlanmis sistemler var...
embedded sistemler buyuk zararlar görcek
Forum Yazılımı : vBulletin v3.7.3, Copyright ©2000-2008, Jelsoft Enterprises Ltd.