Linux saati 19 Ocak 2038'de başarısız olur mu 3:14:08?

Hayır, başarısız olmayacak. En kötü durumda, bir programcı bakış açısıyla beklendiği gibi çalışacaktır: 1901-12-13 20:45:52 tarihine kadar tekrar satılacaktır:

Bu durumda, gerçekleşene kadar mevcut dağıtımlarınızı güncellemezsiniz. " Güncelleme kolaydır. Bu güncellemelerin biri mutlaka bir düzeltme içerecektir. " chocobai gibi .

2000'den önce 16 bitlik makinelerde aynı sorun / soru olduğunu ve sonuçta sorun olmadığını hatırlıyorum.

Wikipedia'dan bir çözüm:

  

64 bit donanımda çalışmak üzere tasarlanmış çoğu işletim sistemi zaten işaretli 64 bit time_t tamsayılarını kullanır. İmzalı bir 64 bitlik değer kullanmak, evrenin tahmini yaşından yirmi kat fazla olan yeni bir sarma tarihi sunar: yaklaşık 292 milyar yıl, Pazar günü, 4 Aralık 292,277,026,596, saat 15:30:08. Tarihler için hesaplamalar yapma yeteneği, tm_year 'nin yıl için 1900'den başlayarak işaretlenmiş 32 bit'lik bir int değerini kullanmasıyla sınırlıdır. Bu yıl yılı en fazla 2,147,485,547 (2,147,483,647 + 1900) ile sınırlar. Bu, programları yürütme sorununu çözerken, çoğu katı veri formatı kullanan ikili veri dosyaları içinde tarih değerlerinin saklanması sorununu çözmez. Ayrıca, uyumluluk katmanları altında çalışan 32 bit programlar için de sorunu çözmez ve time_t dışındaki değişkenlerin değişkenlerinde zaman değerlerini yanlış olarak saklayan programlar için sorunu çözemeyebilir.

Ubuntu 13.04'ü 64-bit'de kullanıyorum ve merakla, manuel olarak saati 2038-01-19 03:13:00 olarak değiştirdim. 03:14:08 sonra hiçbir şey olmamıştı:

Yani bu sorun hakkında endişelenecek bir şey yok.

Daha fazla bilgi için:

• Yıl 2038 sorunu - Vikipedi .
• Zaman Sonu (Unix) - Sayıphil .

Bilgisayarınızın saatinin aşağıdaki Perl komut dosyasını kullanarak çöküp çökmeyeceğini kontrol edebilirsiniz:

#!/usr/bin/perl
use POSIX;
$ENV{'TZ'} = "GMT";
for ($clock = 2147483641; $clock < 2147483651; $clock++) {
    print ctime($clock);
}

Bilgisayarınız iyi olacaksa, bunu alacaksınız:

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

Bilgisayarınız benimki gibi ise, şu şekilde etrafı saracaktır:

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

Bunu da yapabilir:

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
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

1996'da bu yazıda kısa bir yazı yazdım ve yayınladım. Bunu göstermek için kısa bir C programı dahil. Ayrıca, Ağ Bağlantıları Protokolü ile NTP ile benzer konular hakkında David Mills'in e-postalarım vardı. Ubuntu 14.04 64-bit dizüstü bilgisayarımda, perl kodu, altta yatan 64-bit lib'lerin değiştirilmiş olması için sınırlama sergilemedi.

Ancak, uzun zaman önce test kodumun çalıştırılması, zamanın UNIX Epoch uygulamasına geri döndüğünü gösteriyor. Yani her şey geçmişin 32 bit koduyla iyi değil.

1996 tarihli makalem, UNIX saati 2038'de bitecek! web sitemde 2000 yılından beri. Bu "UNIX Zaman" başlıklı bir varyant 1998 yılında "Y2K Millennium Computing for 2000 Yılı En İyi Uygulamalar" ISBN 0136465064 sürümünde yayınlandı.

64-bit Linux hazırdır, en azından çekirdek işletim sistemi arayüzlerinden bahsediyorsanız (bireysel uygulamalar elbette hala sabitleyebilir). time_t geleneksel olarak 64-bit linux üzerindeki "long" ve "long" için bir takma ad olarak tanımlanmıştır.

32-bit Linux (ve 64-bit Linux'taki 32-bit ikili dosyalar için uyumluluk katmanı) durumu çok daha az belirgindir. Bozuk ve mevcut tüm ikili dosyaları kırmadan düzeltmek kolay bir iş değildir. Bir sürü API, time_t kullanır ve birçok durumda, veri yapılarının bir parçası olarak gömülür, bu yüzden yalnızca API'lerin birlikte çalıştıkları veri yapılarının çoğaltılması gerekmemesi gerekir.

Geriye dönük bir düzeyde uyumluluk olsa bile, doğru zaman almak isteyen tüm ikili dosyaların yeni 64 bit zaman arayüzlerini kullanmak için yeniden oluşturulması gerekir.

Bazı çalışmalar yapılmış (bkz. örneğin İşte ve İşte ) ancak tam bir çözümden hala çok yol aldık. Y2K38 güvenli genel amaçlı 32-bit dağıtımlar olup olmayacağı açık değildir.