Zaman damgası, 2038 yılı 64 bit Ubuntu sistemi için sorun

64 bit Ubuntu sistemi kullanıyorum.

Şu anda MariaDB içeren bir proje üzerinde çalışıyorum. Projeye zaman damgası tekniğini tanıtmayı planlıyorum, böylece insanlar farklı zaman dilimleri için doğru zamanı alacaklar.

2038 yılı sorunuyla ilgili zaman damgası için bazı makaleler duydum ve okudum. Birçok makale, “biraz” daha fazla zaman almak için 64 bitlik bir sistem kullandığımızı gösteriyor.

Bu “bit” ne kadar zamana işaret ediyor? Web uygulamalarını sonuna kadar yönetebilmemiz için yeterince uzun mu? Durum böyle değilse, sadece iki yıl uzatma gibi, yani 2040 yılı geldiğinde, düzgün çalışmayan uygulamalarımız olacak mı?

14.04 64-bit time

— tet
kaynak

64 bit time_ttam sayı kullanan 64 bit sistemler size 'biraz' zaman kazandıracak - 4 Aralık Pazar günü saat 15:30: 08'e kadar 292.277.026.596. Umarım başvuru için yeterince uzun;)

— Ron

Size biraz daha "biraz" vermiyor. Size tam olarak 32 bit daha verir.

— user12205

64 bit zaman damgaları, bu geçici önlemlerin başka bir tanesidir. Peki ya 100.000.000.000.000 CE’de Ütopya Projesi’nde çalışan insanlar? İşlevsel bilgisayar sistemlerine de ihtiyaçları olacak! 128-bit zaman damgalarının kullanılması, sadece evrenin bu yinelemesinden değil, birçoğundan başka herhangi bir zamanı benzersiz bir şekilde tanımlamamıza izin verir.

— Blacklight Shining

Bu sitede daha önce herhangi bir cevap kabul etmediyseniz: Aşağıdaki cevaplardan biri size yardımcı olduysa , metninin solundaki gri renkli işarete tıklamayı unutmayın , yani Evet, bu cevap geçerli ! ;-)

— Fabby

Yanıtlar:

Kelimenin tam anlamıyla bir "bit" satın alma seçeneği varsa, yani imzalı bir 32bit tamsayıdan işaretsiz bir 32bit tamsayıya aktarma, işler 2106'da çalışmaya devam eder.

64 bit'e aktarma "biraz daha iyi" dir. Yüzlerce milyar yıllık bir çözüm alıyorsunuz.

Ve Ubuntu bunu yapar:

$ uname -p
x86_64

$ date --date=9090-01-01 +%s
224685532800

Ancak, bu işletim sistemi seviyesi. Sadece Ubuntu'nun 64bit bir tamsayı kullanması, MySQL / MariaDB'nin zaman damgalarını saklamak için kullanacağı anlamına gelmez . 2038'den sonraki tarihler şu an için önemliyse, hemen test etmeye başlayın.

Aslında sana biraz zaman kazandırabilirim. Hala kırılmış. Bu hata, bir on yıl önce bildirildi, ancak ana testi hala 64bit int ile başarısız olur.

mysql> select from_unixtime(2548990800);
+---------------------------+
| from_unixtime(2548990800) |
+---------------------------+
| NULL                      |
+---------------------------+
1 row in set (0.00 sec)

Bu depolama bile değil. Biraz acıklı.

(Ve evet, bu MariaDB'de çalıştırıldı, sürüm 10.1)

— Oli
kaynak

10 yıl geçmiş, düzeltmek için hala 22 yılları var. <Haçlar parmaklar> ...

— Mindwin

NB: İmzasız 32 bit tamsayıları kullanmak bir kesektir .

— Kevin

Hiç bir tamsayı olarak saklamayın. ISO 8601 biçiminde bir tarih dizesi olarak saklayın . Bu, İnternet genelinde kullanılan standart formattır.

9999-12-31T23:59:59+00:00

— dobey
kaynak

Hepimiz Year10K Bug'a bir bardak kaldıralım! ;) Fakat ciddiyette, dizeler gerçekten uzatılabilir olsa da, nispeten büyükler (örneğin 200 bit!) Ve ilkel sayıları ayrıştırıp işlemek, bazilyon kat daha hızlı. Bu önemli.

— Oli

Bu görüntüleme için harika bir formattır - ve sadece bunun için. Başka bir şey için (yani, verileri kullanıcıya göre biçimlendirmeye karar verdiğiniz son ana kadar), karşılaştırmak, aritmetik yapmak, vb. Bir tamsayı olarak Unix zaman damgasını (veya kayan nokta) daha iyidir.

— egmont

@Oli Gerçekten önemliyse önemlidir. UNIX döneminden daha eski zamanlarda bu çözüm başarısız olmaz. Format, protokollerin ve API’lerin tüm İnternet üzerinden tarihler için kullanılan standarttır. MariaDB sütununda bir şey saklıyorsanız, o zaman gerçekten, bunu diskte saklamanız gerekir. Tabii ki, bellekte belki daha uygun bir veri yapısına depolamak istersiniz. Her zaman UTC kullanıyorsanız son 40 bit'e de ihtiyacınız olmaz.

— dobey