Epoch'tan Bu Yana Geçen Süre

 (aphyr.com)
2 puan yazan GN⁺ 2024-12-27 | 1 yorum | WhatsApp'ta paylaş
  • POSIX time/Unix time çoğunlukla 1970-01-01 00:00:00’dan bu yana geçen saniye sayısı olarak anılsa da, gerçekte artık saniyeleri yok sayan UTC tabanlı bir değer olduğundan gerçek geçen saniyelerle örtüşmez
  • 2024-12-25 18:51:26 UTC itibarıyla POSIX time 1735152686’dır; epoch’tan bu yana gerçekten geçen süre ise 1735152713 saniyedir, yani arada 27 saniye fark vardır
  • IEEE 1003.1, seconds since the Epoch tanımında bir günü her zaman 86.400 saniye olarak hesaplar; standardın eki de 1970’ten sonra eklenen 14 artık saniyeyi uyumluluk ve hesaplama kolaylığı için yok sayar
  • UTC, güneş günüyle farkı azaltmak için artık saniye ekler; bu sırada POSIX time geriye sıçradığı için Linux, Qantas, Cloudflare DNS gibi sistemlerde arıza örnekleri yaşanmıştır
  • Tek bir bilgisayarda zaman aralığı ölçmek için CLOCK_MONOTONIC veya CLOCK_BOOTTIME daha uygundur; POSIX timestamp ile uyumlu olmak gerekiyorsa leap smear ya da POSIX↔TAI dönüşümü düşünülmelidir

POSIX time gerçek geçen saniye sayısı değildir

  • JavaScript Date, GNU coreutils, Linux time(2), Go time.Unix, MySQL datetime, Ruby Time, Cassandra timestamp gibi araçlar POSIX time’ı çoğunlukla Unix epoch’tan bu yana geçen saniye sayısı gibi ele alır
  • Ancak bu ifade genel sezgiyle tam olarak uyuşmaz
    • Örnek zaman: 2024-12-25 18:51:26 UTC
    • POSIX time: 1735152686
    • POSIX epoch’tan bu yana gerçekten geçen saniye: 1735152713
    • Fark: 27 saniye
  • Bu fark, POSIX time’ın IEEE 1003.1 içinde UTC’den türetilmesine rağmen, tüm günleri tam olarak 86.400 saniye varsaymasından kaynaklanır
  • Standarttaki seconds since the Epoch tanımı değeri tm_sec, tm_min, tm_hour, tm_yday, tm_year kullanarak hesaplar; 1970’ten önceki yıllarla veya negatif değerlerle ilişkisini tanımlamaz
  • Gerçek bir günün uzunluğu her zaman 86.400 saniye değildir ve zamana göre değişir
    • UTC tarihinin güneş gününden fazla uzaklaşmaması için astronomlar düzenli aralıklarla artık saniye ilan eder
    • Bunun sonucunda POSIX time birkaç yılda bir geriye sıçrayabilir
    • Bir gün ileriye de sıçrayabilir
  • Artık saniyeler geçmişte gerçek arızalara yol açmıştır

Standardın uzlaşması ve pratik alternatifler

  • IEEE 1003 Ek B, standardın yayımlandığı sırada 1970-01-01’den sonra 14 artık saniye eklenmiş olsa da, kolay hesaplama ve uyumluluk için bu 14 saniyenin yok sayıldığını belirtir
  • Standart, çoğu sistemdeki “time” değerinin sürekli arttığını varsayar ve artık saniye sırasında da bu değerin artması gerektiği yönünde seçim yapar
    • Aynı zamanda çoğu sistemin artık saniyeleri takip etmeyebileceğini veya standart zaman referansına senkronize olmayabileceğini varsayar
    • Bu yüzden seconds since the Epoch değerinin referans zaman ile epoch arasındaki tam saniye sayısını mutlaka göstermesini şart koşmaz
    • Uygulamaların bu değeri epoch’tan bu yana geçen saniye sayısı gibi ele alabilmesi yeterlidir; gereken doğruluğun sistem tedarikçileri ve yöneticileri tarafından sağlanması gerektiği görüşündedir
  • Dağıtık uygulamalarda olaylar timestamp ile senkronize edildiğinden tutarlı yorumlama önemli hale gelebilir
    • Artık saniye birikimi öngörülemez
    • Epoch’tan bu yana artık saniye sayısının artması olasıdır
    • Standart, astronomik ölçekte kısa süreli uygulamalar arasında zaman senkronizasyonuyla daha çok ilgilenir
  • Gerçek sistemler zaman biraz sapsa da genellikle çalışır; ancak artık saniyeler nadirdir ve “epoch’tan bu yana geçen saniye sayısı” biçimindeki doğrusal sezgi güçlü olduğundan keşfedilmemiş hatalar birikebilir
  • Duruma göre alternatifler şunlardır
    • Tek bir bilgisayarda iki olay arasındaki duration’ı hesaplıyorsanız CLOCK_MONOTONIC, hatta CLOCK_BOOTTIME kullanın
    • POSIX time varsayan diğer sistemlerle timestamp alışverişi yapmanız gerekmiyorsa TAI, GPS, LORAN kullanın
    • POSIX timestamp sistemleriyle kabaca uyumlu olmanız gerekiyorsa leap smear ile artık saniyeyi daha uzun bir zaman aralığına yayın
    • qntm’in t-a-i gibi kütüphanelerle POSIX ve TAI arasında dönüşüm yapılabilir
  • Artık saniyeleri kaldırmaya yönelik çalışmalar sürüyor ve bunun 2035’e kadar gerçekleşmesi bekleniyor
    • Bir gün 86.400 saniyedir varsayımına dayanan her şeye dönüşüm tablosu eklemek gibi ek çalışmalar gerekecek
    • 2035 sonrasındaki zamanlar için “iki zaman arasında kaç saniye vardır” gibi sorular çok daha basit hale gelebilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-12-27
Hacker News yorumları

  • Vernor Vinge’in 2000 tarihli bilimkurgu romanı A Deepness in the Sky’ı yeni okudum; epoch’tan bu yana geçen saniyelere (seconds since the epoch) beklenmedik bir gönderme yapan harika bir kitap.
    “Traders’ın zamanı ölçme biçimine bakın…” diye başlayıp, Qeng Ho’nun zamanı insanlığın Old Earth’ün Ay’ına ilk ayak bastığı andan itibaren saniye cinsinden saydığını, ama daha yakından bakınca başlangıç anının aslında yaklaşık 15 milyon saniye sonrası, insanlığın erken dönem bilgisayar işletim sistemlerinden birinin sıfırıncı saniyesi olduğunu anlatıyor.

    • Bu kitap kişisel olarak tüm zamanların favorilerimden biri ve ince yazılım referanslarını kullanma biçimini gerçekten seviyorum.
      Daha fazla “uzayda bilgisayar bilimi” istiyorsanız Bobiverse serisini, daha fazla “insan + simülasyon + bilgisayar” incelemesi istiyorsanız Permutation City’yi öneririm.

  • Zaman ölçümü hakkında ne zaman okusam mutlaka yeni bir şey öğreniyorum. Unix zamanını, rollover’ı saymazsak zamanı izlemenin en basit yolu sanıyordum; artık saniyeleri biliyordum ama bunun burada da geçerli olduğunu düşünmemiştim.
    “UTC, GPS, LORAN and TAI” bağlantısını da okudum; GPS zamanının artık saniyeleri yansıtmaması ilginç bir karşıtlık.

    • Bir şeyin kaç saniye önce/sonra gerçekleştiğini söylemek basit. Zor olan, o ana bir takvim tarihi atamak.
    • Sonuç olarak TAI’nin en basit seçenek olduğunu, diğer biçimlerin yalnızca gerektiğinde TAI’den dönüştürülerek kullanılması gerektiğini düşünüyorum. Örneğin gösterim veya birlikte çalışabilirlik için.

  • “2035’e kadar artık saniyeleri kaldırmaya yönelik çalışmalar sürüyor” planı pek hoşuma gitmiyor.
    UTC’nin özü, TAI’den tam sayı saniye kadar uzak olup ortalama güneş zamanına (MST) yakın kalmasıdır. Artık MST’yi izlemeyeceksek doğrudan TAI’ye geçmeliyiz.
    UTC’nin MST’den uzaklaşmasına izin verirsek, geçmiş artık saniyeleri hâlâ ele almak zorunda kalırız ama o artık saniyelerin artık bir amacı kalmaz; ne yardan ne serden bir durum oluşur.

    • MST’den uzaklaşmanın getirisinden çok maliyeti olduğuna katılıyorum.
      Yine de bu öneri tamamen anlamsız değil. Mevcut UTC zaman yönetimini değiştirmeden, 2035 sonrası iki zaman damgası arasındaki farkın doğru fiziksel saniye sayısı olmasını amaçlıyor.
      Yine de MST zaten UTC’nin bir işleviyken bunu kaldırmak tuhaf görünüyor.
    • İdeal bir dünyada bilgisayar sistemleri zamanı izlemek için TAI kullanır, TZ veritabanını kullanarak UTC’ye veya yerel saate dönüştürürdü.
      Ama gerçekte birçok sistem yanlış seçimi yaptı; özellikle de UNIX bunun en büyük nedeni. Bu tercih sayısız sisteme ve düzenlemeye o kadar derin işlemiş durumda ki “doğrudan TAI’ye geçmek” fiilen imkânsız.
      Bu yüzden UTC’yi “yeni TAI” olarak yeniden yorumlamak daha kolay. Bir gün eski UTC’nin başka bir adla yeniden ortaya çıkmasına şaşırmam.
    • TAI diye ayrı bir varlık yok. UTC’den başlayıp ilgilendiğiniz artık saniye sayısını çıkarınca elde ettiğiniz şey TAI’dir. TAI ayrı bir standart nicelik olarak sürdürülmüyor.
      Çoğu ülkede, hatta belki hepsinde, sivil zaman UTC’ye dayanır. Biraz daha saf diye dünya genelindeki saatleri yaklaşık 30 saniye geri alacak değiliz.
      GPS zamanının da TAI ile bir ofseti var ama kimse bunu pek umursamıyor. Unix epoch’u da aynı; sonuç tutarlıysa yeterli.
    • Hack kelimenin tam anlamıyla önemsiz. Ayda bir UTC # ET olup olmadığını kontrol edin; farklıysa Leap_Second adlı bir dosya oluşturun. Her ay bu dosyanın varlığına bakın; varsa silip Leap_Seconds dosyasındaki değere 1 ekleyin ve LSSE adlı bir yedek oluşturun.
      “You are not expected to understand this.” İki sistemi de sürdürme yöntemi bu. İsterseniz hash ya da arama tablosu olarak da yapabilirsiniz.

  • Modern UTC epoch’unun 1 Ocak 1972 olması da önemli. Ondan önce UTC, TAI’den farklı saniye uzunlukları kullanıyordu.
    1971 sonunda ara aşama olarak tam 0,107758 TAI saniyelik son düzensiz sıçrama vardı ve 1958–1971 arasında UTC veya TAI’deki küçük zaman adımları ile frekans ayarlamalarının toplamı tam 10 saniye olacak şekilde ayarlanmıştı. Bu yüzden 1 Ocak 1972 00:00:00 UTC, tam olarak 1 Ocak 1972 00:00:10 TAI idi; o tarihten sonra fark tam sayı saniyeler oldu.
    Aynı zamanda UTC’nin tik hızı TAI ile tamamen aynı hale geldi ve UTC, UT2 yerine UT1’i izlemeye başladı. Dolayısıyla 1970 ve 1971’deki Unix zamanı, o dönemin gerçek UTC zamanı ile uyuşmaz.
    https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
    https://en.wikipedia.org/wiki/Unix_time#UTC_basis

    • Bu nedenle bugün hayatta olan bazı insanlar tam yaşlarını (saniye cinsinden) bilemez ve gelecekte de bilemeyecek.
      Doğum belgesindeki zamanın saniye düzeyinde doğru olduğunu varsaysak bile. Çünkü bu kişilerin yaşamlarının bir bölümünde “1 saniyenin uzunluğu” sayılan değer, bugün genelde düşündüğümüz 1 saniyeye kıyasla epey farklıydı.
      Burada saniye, sezyum-133 atomunun bozulmamış temel durum aşırı ince geçiş frekansı olan 9.192.631.770/s’ye dayalı saniye anlamına gelir.

  • Yakın zamanda bir borsa için kod yazdım; sistem VAX ya da daha doğrusu OpenVMS üzerinde çalışıyordu ve epoch 17 Kasım 1858’di.
    Kariyerimde Unix dışı bir epoch’u ilk kez görmüştüm; neyse ki kullandığım kodda Unix epoch olarak soyutlanmıştı.

    • 1858 epoch’u, astronomide standart takvim olan Julian Day’den geliyor gibi. Burada 0. gün MÖ 4713’tür.
      https://www.slac.stanford.edu/~rkj/crazytime.txt
      1950’lerin bilgisayar belleğine bu tarihleri sığdırmak için takvim 2,4 milyon gün ötelenmiş ve bunun sonucunda 0. gün 17 Kasım 1858 olmuş.
    • Excel’in epoch’u olan 1 Ocak 1900 ile Basic’in 31 Aralık 1899’u arasındaki çakışmaya dair eski bir Microsoft anekdotu da var.
      https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
    • Bilinmeye değer bir başka yaygın bilişim sistemi olarak, Windows epoch 1 Ocak 1601’dir.
    • Klasik MacOS, Apple’ın HFS dosya sistemi(OS X’te de kullanıldı) ve PalmOS’un epoch’u 1 Ocak 1904 idi.
      macOS/Swift Foundation API’si NSDate.timeIntervalSinceReferenceDate, epoch olarak 1 Ocak 2001’i kullanır.
      Wikipedia’da da faydalı bir liste var: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
    • PostgreSQL, zaman damgalarını saklamak için dahili olarak 2000-01-01 epoch’unu kullanır.

  • Bazı anlar POSIX zaman damgası ile ifade edilemez; bazı POSIX zaman damgaları da gerçek zamandaki bir ana karşılık gelmez.

    • Gerçek zamandaki bir ana karşılık gelmeyen POSIX zaman damgalarının ne olduğunu merak ediyorum. Yoksa gelecekte negatif artık saniye olursa onu mu kastediyor?
    • Bu her zaman böyleydi. Unix zamanında 1970 öncesi tanımlı değildir.
    • Yine de en azından bir POSIX zaman damgası birden fazla gerçek ana karşılık gelmez. İnsanların her şey için kullandığı tek temsil biçiminden daha iyi.
    • Öyle değil.
      Bu, ISO 8601 yılı olmayan anlar olduğunu söylemeye benziyor. Her anın bir yılı vardır; sadece bazı yıllar diğerlerinden daha uzundur.
      https://time.is/UTC adresini açıp izlerseniz zaman monoton biçimde artar; arada sırada sadece bir saniye çok az daha uzun olur. Örneğin 24 saat boyunca yaklaşık %0,001 daha uzun olması gibi.

  • Veritabanında tarih saklarken her zaman Unix epoch zamanı olarak saklarım ve tarih alanına zaman dilimi bilgisini yazmam. Zaman dilimini bilme gereksinimi varsa ayrıca saklarım.
    Bunun yerine zaman damgasını TAI biçiminde saklayıp gerektiğinde UTC’ye çeviren bir fonksiyon kullanarak Dünya ile ilgili düzeltmeler gerektiğinde bunları ele almak mı gerekir diye merak ediyorum.
    Zaman dilimlerinin mayın tarlası olduğunu biliyorum; ama bu da zaman dilimi sınırlarının zaman içinde değiştiği insani bir kurgudan ibaret. Mutlak zamana sabitleyip gerektiğinde istenen yerel zaman biçiminde render etmek gerekiyor gibi.

    • Evet. TAI veya benzeri bir biçim, “sistem” zamanını takip etmenin tek makul yoludur; daha üst seviye sistemler de bunu insanların gördüğü zamana çevirmelidir.
      Artık saniye ayarlaması, zaman dilimi dönüşümüyle aynı yerde yapılmalıdır. Ne yazık ki Unix yanlış şeyi standartlaştırdı ve migrasyon zor.
    • Genelde hayır; hatta neredeyse hiçbir zaman. Çoğu yazılım artık saniyeleri üstünü örterek işleyecek şekilde yazılmıştır ve pratikte bu yalnızca saat senkronizasyon katmanında olur. Örneğin chrony artık saniye smear uygulamasını destekler.
      Dolayısıyla tüm saatler zaten UTC’ye göre ayarlanmıştır. Saklarken UTC’den TAI’ye çevirip okurken tekrar geri çevirmek gerekeceği için ortalık karışır.
    • “Tarih alanına zaman dilimi bilgisini yazmam” kısmına gelirsek, aslında zaman damgası sütunlarında zaman dilimini korumaya izin veren veritabanı sayısı çok azdır.
      Genelde veritabanlarında saklanan zaman damgası için bir zaman dilimi kavramı yoktur(SQL Server) ya da “zaman dilimi farkında” zaman damgası tipi sunarlar ama girdiyi UTC’ye çevirip özgün zaman dilimini atarlar(MySQL, Postgres).
      Bildiğim kadarıyla yalnızca Oracle, with time zone tipinde yerel olmayan zaman dilimlerini gerçekten gidiş-dönüş koruyabiliyor.
    • Sistemin ne sakladığına bağlı. Çoğu sistem birkaç yılda bir 1 saniye sapmayı önemsemez.
      Bazı hesaplamalarda 1 saniyelik fark büyük sorundur. En yaygın kullanılan biçim olmayan bir şeyi benimserken dikkatli olmak ve standarttan sapmak için geçerli bir nedeniniz olmak zorunda. Sadece farklı olması bile maliyeti ciddi şekilde artırabilir.
    • Veritabanının yerel tarih-saat alanlarını kullanmak yeterli.

  • Bu yazı yüzünden Noel’im mahvolmuş gibi hissediyorum. Kutsal hiçbir şey yok mu? Saniyeler epoch’tan bu yana geçen saniyeler olmalı.
    Güneş gününden biraz sapmasını neden umursamamız gerektiğini anlamıyorum. Epoch’tan bu yana geçen saniyeleri tarih gösterimine çeviren dönüştürücü düzeltmeyi üstlense olmaz mı?

    • Şu anki yöntem aslında istediğimiz yöntem. 86400 saniye = 1 gün ve UTC gece yarısının her zaman 86400’ün katı olduğu varsayımıyla çalışıyoruz.
      Tüm yazılımların artık saniye eklemelerini hard-code etmesini, smear işlemini ele almasını ve yeni bir artık saniye eklendiğinde bir ay içinde güncelleme yöntemi gerektirmesini istemeyiz.
      Şimdiye kadar bunun için endişelenmemiz ya da düşünmemiz gerekmedi; bundan sonra da gerek yok. Doğru şekilde ele alınıyor.

  • Artık saniyelerin yerini ekvatora yerleştirilmiş dev roketler almalı. Saatleri ayarlamayalım, gezegeni ayarlayalım.

    • Hesap hatası yüzünden Dünya çok yavaşlar ya da hızlanırsa pek komik olmaz gibi.
      İslam geleneğinde kıyamet ve Deccal(Dajjal) hakkında anlatılanlarda da bunun gerçekten yaşanmasına benzer bir bölüm var. “Deccal’in ilk günü bir yıl gibi, ikinci günü bir ay gibi, üçüncü günü bir hafta gibi olacak” denir; birçok kişi bunu kelimenin tam anlamıyla, yani Dünya’nın dönüşünün gerçekten yavaşlayıp sonunda yön değiştirerek güneşin batıdan doğduğu kozmik bir olay olarak kabul eder. Bu, insanlığın sonunun son alametidir.

  • Artık saniye yüzünden epoch’un date +%s’in ima ettiğinden 29 saniye daha eski hale gelmesi neyi değiştirir, anlamıyorum
    Herkesin mevcut zamanı gösteren bir N sayısı üzerinde anlaşması çok daha önemli. Varsayımsal -29 saniye gerçek dünyayı etkilemez. 30 yıl önceki bir hedefe füze nişanlama rutini çalıştıracak değiliz ya
    Artık saniyenin kaldırılmasını destekliyorum, ama zaman tutarsızlığını vurgulamanın faydalı olduğunu düşünmüyorum. Teknik olarak doğru olsa bile

    • Kısa bir olayın süresini başlangıç/bitiş zamanlarından hesapladığınız bir durumu hayal edebilirsiniz. Bu aralık artık saniyeye denk gelirse, zaman damgalarının nasıl işlendiğine bağlı olarak süre epey farklı çıkabilir
      Daha önemlisi geleceğe etkisi. Geçmiş zaman damgalarının basit bir “şimdi - N saniye” hesabından birkaç saniye farklı olabilmesi çoğu durumda ilginç bir bilgi sayılır; ama gelecekte bir noktada tüm saatlerin yeniden 1 saniye kaydırılmak zorunda kalabilmesi daha önemli. Bunu hesaba katmanın ciddi çaba gerektirdiği pek çok gerçek dünya örneği var
    • Bazı şeyler için önemli. Böyle varsayımsal artık saniyeler olmasa, örneğin yerel öğle vaktinde Güneş’in konumu 29 saniyelik sapma gösterir