`"Australia/Lord_Howe"` en tuhaf saat dilimi

• Saat dilimleri karmaşıktır, ancak bilgisayarların bunu uygulaması gerektiği için tuhaflıkları yalnızca sonlu bir aralıktadır.
  • Asia/Kathmandu, UTC'ye göre alışılmadık bir ofsete sahiptir.
  • Africa/Casablanca, saat dilimi modeline iyi uymadığı için hardcode edilmiştir.
  • America/Nuuk, yaz saatine -01:00'da başlar.
  • Africa/Cairo ve America/Santiago, yaz saatine 24:00'te (00:00 değil) başlar.
  • Australia/Lord_Howe, en tuhaf yaz saati kuralına sahiptir.

PGXIIREAM: Papa XIII. Gregorius her şeyi yönetiyor

• Dünyanın büyük bölümü Gregoryen takvime dayalı bir zaman sistemi kullanır.
• Gregoryen takvim, güneşin konumunu yıl boyunca tutarlı tutmak için son derece kullanışlıdır.
• UTC, Gregoryen takvimin modern resmileştirilmiş hâlidir ve tüm dünya zamanı buna göre ayarlar.

Artık saniyeler önemli değil

• Dünya'nın dönüşü yavaşladığı için bunu telafi etmek amacıyla artık saniyeler eklenir.
• Programlama dilleri 61 saniyeyi ifade etmediği için artık saniyeler göz ardı edilebilir.
• Bulut sağlayıcıları bu sorunu, artık saniye sırasında saatleri yavaşlatarak çözer.

Tuhaf saat dilimleri

Asia/Kathmandu alışılmadık bir ofsete sahiptir

• Nepal, UTC'nin 5 saat 45 dakika ilerisindedir.
• Bilgisayarlar bunu IANA saat dilimi veritabanı üzerinden bilir.

PDT veya CET gibi dizgelerin bir anlamı yoktur

• Saat dilimi tanımlayıcıları belirsiz olabilir ve birçok saat dilimi aynı tanımlayıcıyı paylaşır.

Yaz saati uygulaması olan saat dilimleri nasıl temsil edilir?

• Yaz saati geçiş kuralları karmaşıktır ve bilgisayarlar yerel saati buna göre hesaplar.

Africa/Casablanca ve Asia/Gaza Ay'ı takip eder, ama saat dilimleri Güneş'i takip eder

• Fas ve Gazze, yaz saatini Ramazan'a göre ayarlar; bu da hardcode edilmiştir.

America/Nuuk, yaz saatine -1'de geçer

• Grönland, yaz saatine Avrupa ile aynı anda başlar, ancak yerel saatte bu -1'de olur.

America/Santiago ve Africa/Cairo, 24:00'te geçiş yapar

• Bu saat dilimleri yaz saatine 24:00'te geçer; bu da bir sonraki güne sarkmak anlamına gelir.

Australia/Lord_Howe, en tuhaf yaz saati geçişine sahiptir

• Lord Howe Adası'nda 30 dakikalık bir yaz saati geçişi vardır.

GN⁺ özeti

• Saat dilimleri karmaşıktır, ancak bilgisayarların bunu uygulaması gerektiği için tuhaflıkları yalnızca sonlu bir aralıktadır.
• Australia/Lord_Howe, 30 dakikalık yaz saati geçişiyle en sıra dışı saat dilimidir.
• Bu yazı, saat dilimlerinin karmaşıklığını anlamak için faydalıdır ve programcıların ilgisini çekebilir.
• Benzer işleve sahip projeler arasında tzdb bulunur.

[GN⁺]

Hacker News yorumları

• tz veritabanının en eğlenceli kısmı, içinde Büyük Patlama zamanına ilişkin bir tahmin bulunması ve Büyük Patlama'dan önce gerçekleşen saat dilimi geçişlerini hesaplamayacak şekilde tasarlanmış olması
  https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... commit mesajı da “Büyük Patlama öncesi zaman damgaları fiziksel olarak şüpheli, o yüzden üretmeyelim” anlamındaydı; hemen ardından ayrı bir commit ile Büyük Patlama öncesindeki leap second'lar da yasaklandı

  • Eskiden Linux/Unix date komutunda geçmiş tarihlerin anlamını ele alan uzun bir man sayfası vardı
    15. yüzyıl civarından örneklerle, bir kralın belirli bir haftayı/ayı sevdiği için tekrar edilmesini emrettiği ya da başka bir kralın belirli bir haftayı sevmediği için takvimden sildirdiği türden hikâyeler vardı; epey ufuk açıcı bir okumaydı ama şimdi bulamıyorum
  • Oldukça pratik bir karar gibi görünüyor. Katkı verenler arasında iğne ucundaki melekler tartışması gibi anlamsız tartışmaları baştan engellemenin iyi bir yolu
    Başka bir deyişle, “Büyük Patlama'dan önceki anlar bu kütüphanenin kapsamı dışındadır; dolayısıyla bir algoritma yalnızca Büyük Patlama öncesinde yanlış değer üretiyorsa, o algoritma kabul edilebilir ve iyileştirilmesine/değiştirilmesine gerek yoktur” sonucuna varılıyor
  • Gerçekten harika bir ayrıntı; ama ayrı olarak, tzdb'nin Unix epoch öncesini de kapsamaya çalışmasına biraz şüpheyle bakıyorum
    O kısımda hatalara kıyasla fayda büyük görünmüyor ve tzdb'nin dağınık karmaşıklığının çoğu zic içinde. Bazen zic başkalarının güvenip üzerine inşa edebileceği bir çıktı olmasaydı daha iyi olurdu diye hissediyorum
  • TZ veritabanındaki eğlenceli bir easter egg. İlk kez duydum ama bu kadar eski saat dilimi verilerini hesaplamaya ne kadar ihtiyaç olur ki diye düşünüyorum
    Saat dilimi teorisi eskimeden önce keşke saat dilimlerinin kendisi ortadan kalksa

• En tuhaf saat diliminin Africa/Addis_Ababa olduğunu düşünüyorum. Asıl Etiyopya yerlileri bu yöntemi kullanmıyor
  Yerelde saatler 6 saat kaydırılıyor; AM döngüsü şafakta, yani sabah 06.00'da başlıyor, PM döngüsü de gün batımı olan akşam 18.00'de başlıyor
  https://en.wikipedia.org/wiki/Time_in_Ethiopia

  • Kenya dâhil Doğu Afrika genelinde yaygın bir yöntem. Gece sabah 06.00'da biter ve sabah 07.00, günün ilk saati olan saa moja olur
    Benzer şekilde gün akşam 18.00'de, thenashara'da biter. Sezgisel olarak İngilizce konuşulan dünyadaki saat anlayışından çok daha mantıklı ve dilin içine yerleşik olduğu için saat karışıklığı da nadir
  • Etiyopya'nın zaman hesabı genel olarak sıra dışı
    https://en.wikipedia.org/wiki/Ethiopian_calendar
    Etiyopya takvimi, 30 günlük 12 aydan ve 13. ayı oluşturan 5 veya 6 artık gün niteliğindeki tarihten oluşur
  • Romalıların zamanı anlama biçimine çok benziyor. Kuzey Afrika'nın birçok eyaletten oluştuğu dönemlerden kalma eski bir iz olup olmadığını merak ediyorum
    https://en.wikipedia.org/wiki/Roman_timekeeping
  • Ekvatora yakın bir ülke için gün döngüsünü tanımlama biçimi olarak o kadar da mantıksız değil
  • Japonya da gece yarısından sonra kapanan tesisler gibi bağlamlarda benzer bir yöntem kullanıyor: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
    İngilizce konuşulan dünyada da eskiden yıl 25 Mart'ta değişirdi: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
    Teknik olarak ikisi de tzdb'nin ele alabileceği şeyler değil. tzdb civil time ile ilgilenir; takvimleri ya da başka hesaplama yöntemlerini kapsamaz

• Asia/Jerusalem'in tuhaflığı, yaz saati uygulamasının din-devlet ayrımı meselesiyle yakından bağlantılı olmasından kaynaklanıyor. Dindar insanlar, gün batımında başlayan bayramlara göre iş gününün uygun olmasını istiyor
  Bu yüzden 2000'lerin ortasına kadar onlarca yıl boyunca yaz saati uygulaması, dini partiler ile seküler partiler arasında her yıl yapılan pazarlıkların sonucuydu ve geçiş tarihi çoğu kez ancak hemen öncesinde belirleniyordu; bu da sık sık sorun yaratıyordu
  Hâlâ Rosh HaShanah'ta yaz saati uygulamasının bitmemesini sağlayan bir istisna bulunduğu için, gelecek kuralları karmaşık görünüyor olabilir

  • Yaz saati uygulamasının faydaları sınırlıyken, özellikle görece güneyde yer alan bir ülke için neden tamamen kaldırılmadığını merak ediyorum
    AB sonunda kaldırmayı başarırsa onlar da izleyebilir gibi
  • Nedeni Hamursuz Bayramı. Seder adı verilen büyük kutlama yemeği gece yarısından sonrasına kadar sürüyor ve çocuklar için de çok önemli bir etkinlik
    Bu yüzden yaz saati uygulamasının zaten geç biten etkinliği daha da geçe bırakması istenmiyor. Ayrıca Yom Kippur oruç gününde orucun 1 saat daha erken bitmesi isteniyordu. Bu tarihlere uydurmaya çalışınca yaz saati uygulaması dönemi fazla kısaldığı için pazarlık gerekiyordu
  • Artık istisna yok. IDT 2013'te ekim ayının son pazar gününe kadar uzatıldı

• “Programlama dilleri 61 saniyelik bir dakikayı ifade edemez” demek doğru değil. Birisi zaten Raku’nun artık saniyeleri desteklediğini söyledi; bu kısmen benim suçum olabilir
  Çünkü Perl 5’in en popüler tarih/saat kütüphanesi olan DateTime.pm artık saniyeleri destekliyor ve DateTime.pmi yazarken bu desteği ben uygulamıştım
  Geriye dönüp bakınca bu neredeyse kesinlikle bir hataydı. Artık saniyeler ile ilgilenen çok az kişi var ve yalnızca “60 saniye eklemek neden bazen 1 dakika eklemekle aynı olmuyor?” gibi tuhaf kafa karışıklıkları yaratıyor
  Özellikle second => 60 değerinin geçerli olup olmadığını doğrulamaya çalıştığımız için kod çok daha karmaşık hale geldi. Kurucu, zaman bileşenlerini ve rastgele bir saat dilimini aldığı için, artık saniye tablosunu kontrol etmek üzere UTC’ye dönüştürmek gerekiyor; ancak bu dönüşümün kendisi de tarihsel nedenlerle artık saniye içeren değerlerle iç içe geçiyor
  Çok küçük bir kazanç için devasa bir keşmekeşe dönüştü; Raku’nun standart tarih/saat kütüphanesi de Perl 5’in DateTime.pminden epey ödünç almış gibi göründüğünden, aynı kötü tasarım kararlarının bir kısmını miras aldığını düşünüyorum

  • Bunu o şekilde uygulamış olman ve sonradan daha zarif bir çözüme dönüp bakabilmen iyi
    Başta düşünce sürecinin nasıl olduğunu merak ediyorum. Soruna fazla mı kaptırmıştın? Bir probleme çok yakın olup uzun süre odaklanınca, bozulmadan önce düzeltmenin verdiği keyif öne geçip böyle şeyler olabiliyor
  • Raku’da Instant sınıfı var
    “Instant, atomik saniyeler ve onların kesirli kısmı ile ölçülen belirli bir andır; herhangi bir epoch’a bağlı ya da onun farkında değildir” şeklinde tanımlanıyor

• Bu yılın başlarında, bir ABD adresi verildiğinde geçerli yerel saati bulan bir fonksiyon yazmam gerekti. Saf yaklaşım, eyaletleri saat dilimlerine statik olarak eşlemek olurdu; ama bunu engelleyen epey istisna var
  Söz konusu uygulamada maliyet ve hız önemli olduğundan, tüm ABD ZIP code’larını UTC ofsetine, yaz saati uygulamasına uyup uymadıklarına vb. eşleyen bir CSV’yi birkaç dolara satın aldık
  pytz IANA saat dilimi adlarını aldığı için sonunda ofset ve yaz saati bilgilerini belirli bir saat dilimine elle eşlemek zorunda kaldık; ABD’nin denizaşırı toprakları ve askeri üsleri nedeniyle Etc saat dilimleri gibi tuhaf semantiklere de ihtiyaç oldu
  [1] https://en.wikipedia.org/wiki/Tz_database#Area

  • Eyalet düzeyi tamamen yanlış çözünürlükte. ABD saat dilimleri county ve yerli rezervasyon bölgelerinin sınırlarını takip eder
    ZIP code muhtemelen yeterli olabilir ama dikkatli olmak gerekir. Adres sayısı çok fazla değilse, daha sağlam yöntem ters coğrafi kodlama yapıp ardından saat dilimi sınır poligonlarından IANA tanımlayıcısını alan bir kütüphane kullanmaktır
    https://github.com/RomanIakovlev/timeshape eski bir meslektaşım tarafından bakımı yapılan bir proje; içeride yaptığımız işlerin bir kısmını açık kaynak olarak yayımlayabilmiştik
  • 1985’te üniversiteden yeni mezun genç bir mühendistim; ABD’deki çeşitli radar sahalarında manyetik teybe kaydedilmiş telemetri verilerini birleştirme işi bana verilmişti
    Bir iki sistem verileri yerel saatle damgalıyordu, geri kalanı UTC kullanıyordu. Yaz saati uygulamasını işleyecek bir algoritma yapmak için eski bir Farmers' Almanac aldım ama kuralları okuyunca umutsuzluğa kapıldım
    Takvimde geçişler için nominal kurallar vardı, ancak Kongre müdahalesi nedeniyle bunların her yıl ayarlandığını ve gelecekte de ayarlanacağını belirten bir dipnot vardı. Patronuma, “Kongre’nin gelecekteki oylamalarını tahmin eden bir algoritma yazabilseydim milyarder olur, bu mühendislik işini bırakırdım” dedim
    Sonunda sanırım son bilinen geçişleri ve geleceğe dönük nominal kuralları kodladık. Herkesin ağa bağlı olmasından önceydi ve kod VAX gibi bağımsız bilgisayarlarda çalışıyordu; dolayısıyla pek başka yol yoktu
    Her biri kendi geçerlilik ve ölçüm kalitesi düşüş durumlarına sahip üç izleme veri kaynağını birleştirmek de kâbustu, ama yine de Kongre’nin gelecekteki davranışlarını tahmin etmekten daha kolaydı
  • İyi yaklaşım, ZIP code’u US/Eastern gibi adlandırılmış bir saat dilimine eşlemektir. Daha sonra UTC ofseti gerekiyorsa, pytz ile ilgili tarihe saat dilimini uygulayıp ofseti elde edebilirsiniz
    Adlandırılmış saat dilimleri sabit oldukları için özeldir. -05:00 gibi UTC ofset saat dilimleri veya EST gibi kısaltmalar, yaz saati uygulaması nedeniyle belirli bir konumda zaman içinde sabit değildir
    Birine saat dilimini sorarken seçenek olarak ofset ya da kısaltma verirseniz herkesin kafası karışır
  • Bu yılın başlarında benzer bir şey yaptım: Adresi enlem/boylama çeviren bir coğrafi konum servisi kullandım, sonra enlem/boylamdan saat dilimini buldum. Tek saat dilimli eyaletler için kısa yol koydum
    Enlem/boylam → saat dilimi dönüşümü için şu Python kütüphanesini kullandım: https://github.com/jannikmi/timezonefinder
    Veri kaynağı da oldukça kaliteli bir kaynak gibi görünüyordu: https://github.com/evansiroky/timezone-boundary-builder/rele...
  • Etc tanımlayıcılarında gerçekten dikkatli olmak gerekiyor. Özellikle tüm tanımlayıcıları olduğu gibi kullanıcıya göstermeye çalıştıysanız daha da öyle
    İlgili dosyada şöyle bir yorum var: “POSIX Greenwich’in batısını pozitif kabul eder, ama pek çok kişi Greenwich’in doğusunu pozitif bekler. Örneğin TZ='Etc/GMT+4' kısaltma olarak -04 kullanır ve UT’den 4 saat geride, yani Greenwich’in batısında anlamına gelir; oysa birçok kişi bunu UT’den 4 saat ileride, doğuda sanır”

• Filistin’in saat dilimi de epey tuhaf
  https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
  Yaz saati uygulaması var ama tarihler sabit değil; hükümet her yıl başlangıç ve bitiş zamanlarını duyuruyor. Bazen bir haftadan az süre kala duyurulduğu için her türlü ilginç sorunun çıkması kaçınılmaz oluyor

  • Aynı fiziksel yerde yaşayan iki kişinin, etnik ve jeopolitik kimliğine göre farklı bir mevcut saati takip etmesi durumu ortaya çıkıyor
    İsrail ve Filistin’in yaz saati başlangıç/bitiş tarihleri her zaman aynı olmak zorunda değil
  • Hâlâ öyle mi bilmiyorum ama Brezilya’da da eskiden böyleydi. Bu yüzden bir uçağı neredeyse kaçırıyordum
  • Asıl yazıda geçen bir konu ve Ramazan ile bağlantılı
  • Siyaset konusuna derinlemesine girmeden de, neden yaz saati uygulamasına çaba harcamaya öncelik verildiğini pek anlayamıyorum. Çok daha fazla dertleri var gibi görünüyor

• 1 saat değil de 30 dakika fark olan bir yaz saati uygulamasına “en tuhaf saat dilimi” demek için çıtanın çok düşük olduğunu düşünüyorum
  Neredeyse diğer her şey daha tuhaf. Antarctica/Troll kesinlikle daha tuhaf geliyor; Fas ve Gazze’nin saat dilimleri ise mevcut sistemle ifade edilemeyecek kadar, en azından farklı türden kurallara sahip. Apple’ın yasak listesine giren, belirli bir tarihin bir gün öncesinde geçiş yapan saat dilimleri de bir şeyleri bozacak kadar tuhaf
  Artık saniyeler konusunda katılıyorum. Programcıların bilmesi gereken yararlı bir bilgiden çok, neredeyse genel kültür/trivia. Bilgisayarlar artık saniyeleri smear ederek işler ve ne zaman gerçekleştiğini bile bilmez. Tamamen unutup yaşayabilirsiniz
  Yine de ülkelerin artık saniyeleri yok sayma biçiminden hesaba katma biçimine geçtiği bir dönem oldu; bu yüzden onlarca yıl önce Avustralya’da GMT+xten UTC+xe geçiş, artık saniyeleri yok saymaktan onları dahil etmeye geçişti. Bu gerçeğin neredeyse evrensel olarak görmezden gelinmesi belki de daha iyi bir şeydir

  • Genel olarak artık saniyelerin trivia olduğu konusunda katılıyorum
    Ama büyük bir kuruluşun “sunucularımız GPS senkronizasyonu ve kendi geliştirdiğimiz PCIe rubidyum atom saati kartı sayesinde milisaniyenin altında zaman doğruluğuna sahip” derken, aynı zamanda “artık saniyeleri bir güne yayarak smear ettiğimiz için sunucu saatinin gerçekte ±0,5 saniye hatalı olması sorun değil” demesi her zaman biraz komik geliyor
    [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
    [2] https://engineering.fb.com/2020/03/18/production-engineering...
  • Ramazan tarihleri iyi bilinen sabit değerler değildir. Çünkü dünyanın belirli bir bölgesinde ayın gerçekten görülüp görülememesine dayanır
    Örneğin gökyüzü çok bulutluysa ay nerede olursa olsun görülemez. Bu da devlet işleyişi için bir takvim uygularken sorun yaratır
    İslami takvimi resmen benimseyen birçok ülke, belirli bir konumdaki tahmini görünürlüğe dayalı olarak önceden hesaplanmış yaklaşık tarihleri kullanır. Dolayısıyla İslami takvim aslında tek bir şey değil; gözlemsel İslami takvim ve öngörü takvimi olmak üzere iki şeye daha yakındır ve ikisi de gerçek ya da öngörülen gözlemin yapıldığı konuma bağlıdır
    Fas’ın ya da Gazze’nin nasıl yaptığını bilmiyorum
  • Antarctica/Troll o kadar da tuhaf değil. Aslında kısa yaz döneminde Cape Town saatini, kalan dönemde ise Norveç saatini kullanıyor
    Ne var ki Norveç saati tesadüfen yaz saati uygulaması kullanıyor
  • Artık saniyeler çoğunlukla trivia’dır, ama birden fazla tarafın zaman sıralaması konusunda kesin olarak anlaşması gereken uygulamalarda kritik önem kazanır. Bunun tipik örneği finansal işlemlerdir
    Birçok piyasa artık saniye sırasında kapalıydı ve birçok banka, hata riskini azaltmak için yerel saat değişikliklerinde hâlâ tüm işlemleri durduruyor
    Pek umursamayan uygulamalarda bile artık saniyeyle ilgili şaşırtıcı derecede çok hata yaşandı; CGPM’nin artık saniyeleri kaldırmaya karar vermesinin iyi nedenleri var
    https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
  • Troll’u aramaya gelmiştim. Bildiğim kadarıyla kış yaz saati uygulaması olan tek yer ve adı sayesinde de ekstra puan alıyor

• Saat dilimi yazılımlarının akrobasisini ele alan harika bir yazı. Gerçekten oldukça esnek
  Tamamı otomatikleştirilmiş sonlu ofsetlerden ibaretse, yaz saati politikalarının illa 60 dakikalık ayarlamalara uyması için bir neden yok
  Bir ülke yıl boyunca sürekli değişen bir ofset kullanmaya karar veremez mi? Ofset arama tablosu çok daha uzar, ama bu yolla yaz saati uygulaması “çözülebilir”. Sürekli azar azar ayarlanacağı için artık saniye gibi fark edilmeyecektir
  Analog saatlere bel bağlayan insanlar artık her seferinde aynı yönde ayar yapmıyor olabilir

  • Elektronik cihazlarda saat senkronizasyonu yaygınlaştığından beri, dinleyen herkese 6 ay boyunca her ayın ilk pazar günü 10 dakika ileri, kalan 6 ay boyunca da her ayın ilk pazar günü 10 dakika geri ayarlamayı öneriyorum
    Ayda bir 10 dakikalık değişiklike uyum sağlamak çok daha kolay, neredeyse fark edilmez; kaçırılsa bile 1 saat yanlış kalmak kadar büyük bir sorun olmaz
  • O yola girerseniz mantıksal sonuç, saat dilimi kavramını tamamen kaldırıp yerel güneş saatine dönmektir
  • Yaz saati uygulamasını “çözmenin” en kolay yolunu görmezden geliyorsunuz
    Yaz saati uygulamasını bırakın. Kişisel olarak kalıcı yaz saati yerine kalıcı standart saati tercih ederim, ama yılda iki kez saatleri değiştirmeyi durdurabileceksek bunu kabul edebilirim
  • Hindistan UTC+5:30’da ve yaz saati uygulaması yapmıyor; bu da dünyayla etkileşiminde ilginç oluyor
    Elbette Çin, meşhur olduğu üzere bu kadar geniş olmasına rağmen tek bir saat dilimine sahip; bu da hem içeride hem dışarıda ilginç durumlar yaratıyor
  • Teorik olarak tzdb ile ifade edilebilir. Elbette sorun çıkaracaktır
    TZif veri biçiminde açıkça görünmeyen gerçekten önemli bir varsayım, yerel saatten UTC saatine giderken en fazla iki olasılık olduğudur
    Pek çok yazılım bu varsayıma dayanıyor; örneğin java.time.LocalDateTime içinde withLaterOffsetAtOverlap() var: https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
    Bu, sabah 2:30’un ne anlama geldiği belirsiz olduğunda olası çözümlerin yalnızca yaz saati öncesi ve sonrası olmak üzere iki tane olduğunu örtük olarak varsayar. Bir saat dilimi saat 2:00’de bir kez geri alıp 2:15’te tekrar geri alarak üç veya daha fazla çözüm üretirse, birçok şey bunu ifade edemez

• tz veritabanında sevdiğim nokta, teknik olarak diff’in diff’i olması
  Her saat dilimi ile UTC arasındaki farkın tarihsel olarak nasıl değiştiğini sakladığı için diff^2 olarak görülebilir. Ama tz veritabanı güncellemeler de aldığı için, o commit diff’in diff’inin diff’i, yani diff^3 olur
  Daha da ileri gidilebilir. Değişiklik günlüğü var ve bu değişiklik günlüğü git’te tutuluyor; dolayısıyla tz değişiklik günlüğüne yapılan bir commit, UTC’ye göre değişiklik listesinin değişiklik listesinin değişiklik listesine yapılan değişikliktir: diff^4

  • UTC’nin, daha geniş anlamda zaman ölçümünün kendisinin de bir diff olduğunu atlamışsınız
  • Diff’in diff’i sadece iki diff’tir. Diff’lerin çarpımı değildir

• Bence işin özü, neredeyse tüm tarih/saatlerin aslında izlenen bir eşleşme kuralları kümesi olarak çerçevelenmesi
  Eşleşme tetiklenene kadar kaç saniye süreceğini tahmin edebilirsiniz, ama gerçekten gerçekleşmeden tamamen emin olamazsınız; bazı durumlarda ise tam olarak hiç gerçekleşmeyebilir
  Sonraki yarısı, “şu andan X saniye sonra olacak gibi görünüyor” şeklindeki delta tahminini “o anda sizin saat diliminizdeki saat Y’yi gösterecek gibi görünüyor” biçimine geri çevirmektir
  Hangi saat diliminin olayı kontrol ettiğini ve hangi saat diliminde gösterildiğini takip etmeyi unutmamak gerekir
  [1] UTC tahmini artık saniye kadar ileri geri sapabilir. TAI daha güvenlidir, ama biri sezyum atomunun davranışını değiştiren ilginç ve yeni bir şey keşfederse bu değişebilir
  [0] Örneğin bir ülke ortadan kalkıp saat dilimi yok olabilir. Ya da saat 1:00’den 2:00’ye atlayabilir; aradaki eksik 1 saat yüzünden 1:30~2:00 aralığı tam olarak hiç gerçekleşmeyebilir