2026 Aralık sonunda artık saniye eklenmeyecek

• IERS Bulletin C 72’ye göre 2026 Aralık sonunda UTC’ye artık saniye eklenmeyeceği için zaman ölçümü ve dağıtım sistemlerinin ayrı bir ekleme işlemi hazırlamasına gerek yok
• UTC ile TAI arasındaki fark, 1 Ocak 2017 saat 00:00 UTC’den bir sonraki duyuruya kadar UTC-TAI = -37 s olarak korunacak
• Artık saniyenin eklenip eklenmeyeceği UT1-TAI değişimine göre belirlenir; olası zamanlar Haziran sonu veya Aralık sonudur
• Bulletin C, her 6 ayda bir UTC zaman adımını (time step) duyurur ya da bir sonraki olası tarihte zaman adımı olmadığını onaylar
• 2026 sonu UTC dağıtımı için yeni bir düzeltme değerine gerek yok; mevcut UTC-TAI = -37 s ilişkisini kullanmaya devam etmek yeterli

---

IERS Bulletin C 72’nin UTC duyurusu

• IERS tarafından 6 Temmuz 2026’da Paris’te yayımlanan Bulletin C 72, 2026 Aralık sonunda artık saniye uygulanmayacağını belirtiyor
• Duyurunun hedefi, zaman ölçümü ve dağıtımından sorumlu kurumlar
• Temel değerler şu iki başlıkta toplanıyor
  • 1 Ocak 2017 saat 00:00 UTC’den bir sonraki duyuruya kadar UTC-TAI = -37 s
  • 2026 Aralık sonunda UTC’de yeni bir zaman adımı yok

Artık saniye kararı ve duyuru döngüsü

• Artık saniye, UT1-TAI değişimine bağlı olarak UTC’ye eklenebilir
• Olası ekleme zamanları her yıl Haziran sonu veya Aralık sonudur
• Bulletin C her 6 ayda bir gönderilir
  • UTC’de zaman adımı oluşursa bunu duyurur
  • Bir sonraki olası tarihte zaman adımı yoksa bunu onaylar

[GN⁺]

Hacker News yorumları

• Bu öngörülemezliğin neden kaynaklandığını merak ediyorum. Dünya’nın kendi ekseni etrafındaki dönüşünü ve Güneş etrafındaki dolanımını virgülden sonra birçok basamağa kadar bildiğimizi sanıyordum; jeolojik faaliyetler veya hava durumu gibi etkenler dönüş hızında farklar yaratıp tahmini zorlaştırıyor olabilir mi?

  • Kısaca söylemek gerekirse, evet. Hava durumu, jeolojik faaliyetler ve akiferlerin tükenmesi ile baraj inşası gibi insanların suyu yer değiştirmesi, buzulların ve buz tabakalarının erimesi; bunların hepsi Dünya’nın dönüş periyodunda ve dönüş ekseninde öngörülmesi zor değişikliklere yol açıyor.
    Hatırladığım kadarıyla bu modeller düşük dereceli trigonometrik polinomlar; yani öngörülemezliği kusursuz modelleseniz bile kesme hatası nedeniyle çok yüksek doğrulukla dağıtılmaları zor. Ayrıca uydular gibi yerlere zaten gömülü oldukları için keyfi biçimde karmaşıklaştırılamazlar.
    Bu arada artık saniye yakında ortadan kalkacak; bildiğim kadarıyla 2035’te aşamalı olarak sonlandırılacak. Russia’nın GLONASS uydularını güncellemek için zamana ihtiyacı olduğundan geciktiğini hatırlıyorum.
  • Evet. Bu etkenler ve daha fazlası var. Ölçüm hassasiyetimiz, gün uzunluğunun yıldan yıla değişen birinci ve ikinci dereceden değişim hızlarından çok daha iyi.
    https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... bununla en ilgili grafik; dikey sıçramalar artık saniyeleri gösteriyor. IERS’te dönüşün başka boyutlarına ilişkin grafikler de var ama bu grafik okunması hoş olanı.
  • Tam da son artık saniyenin ne zaman eklendiğine bakmak için Wikipedia maddesini kontrol etmiştim; yanıt da orada var.
    “Dünya’nın dönüş hızı iklimsel ve jeolojik olaylara tepki olarak değiştiğinden, UTC artık saniyeleri düzensiz yerleştirilir ve kesin olarak öngörülemez.”
    https://en.wikipedia.org/wiki/Leap_second
  • Aslında tam tersine daha yakın. Dünya’nın dönüşü yıldan yıla birkaç saniye mertebesinde bile değişebilir, ama yüzlerce yıl boyunca bakıldığında dalgalanmalar büyük ölçüde birbirini götürür.
    Bu yüzden artık saniye eklemeye veya çıkarmaya çalışmanın pek iyi bir fikir olmadığını düşünüyorum. Bu tür şeyleri fiilen yalnızca uzay ajansları önemsiyor; onlar istedikleri düzeltmeyi uygulayabilir ve bunun herkesi etkilemesine gerek yok.
    Sıradan insanlar için bu drift’in pratik etkisi aşağı yukarı GPS’ten ibaret; GPS de zaten kendi saatiyle olan ofseti gönderiyor, alıcı bunu düzeltebiliyor. GPS saati ne UTC ile ne de TAI ile aynı.
  • https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co... adresine bakabilirsiniz.

• Bu daha çok anti-haber değil mi? Günümüz bilişim sistemlerinde fazla sorun çıkardığı için, ayrıca duyurulana kadar artık saniye uygulamasının durdurulduğunu belli belirsiz hatırlıyorum.
  Şu anda fark 37 saniye ve kimsenin Christmas’ın Easter civarına kayacağından endişelenmesine gerek yok. Bence bu mesele, pek çok başka soruna kıyasla gelecek nesillere çok daha sorumlu biçimde devredilebilir.
  Her 6 ayda bir duyuru yapılması yalnızca özgün uluslararası anlaşma metnine uymaya yönelik bir prosedür.

  • Henüz öyle olmadı. Bu sadece bir öneri ve resmî sonlandırmanın 2035’ten önce gerçekleşmesi muhtemelen zor.
    Bir süredir artık saniye olmamasının nedeni, TAI ile UT1 arasındaki drift’in yavaşlaması ve aslında çok yavaş biçimde ters yönde ilerliyor olması.
  • Duyuru süresinin yalnızca 6 ay olması bana akıl almaz geliyor ve sorunun kaynağı muhtemelen bu.
    Zaman ±60 saniye kadar yanlış olsa bile kimse fark etmeyeceğine göre, yaklaşık 10 yılda bir keyfi bir artık saniye ekleyip bunu 10 yıl önceden duyurmak, herkesin sistemlerini toparlaması için zaman tanımak açısından daha yönetilebilir görünüyor. Tüm dünyanın koordineli şekilde uygulaması için 6 ay gülünç derecede iyimser.

• 5 yaşındaki birine anlatır gibi söylersek, bunun UNIX zaman damgalarını nasıl etkilediğini merak ediyorum. Özellikle bakım modunda olan ya da neredeyse hiç yönetilmeyen şeyler açısından.
  Benim yaptığım işte bu düzeyde hassasiyete gerek yok, ama buna ihtiyaç duyan alanlar mutlaka vardır.

  • UNIX zaman damgaları artık saniyeleri tamamen yok sayar ve yokmuş gibi ele alır.
    Bu yüzden artık saniye eklendiğinde UNIX zaman damgasıyla referans verilemeyen fiziksel bir saniye oluşabilir; artık saniye silindiğinde ise gerçekte var olmayan bir saniyeye ait bir UNIX zaman damgası oluşabilir.
  • Her artık saniye eklendiğinde Google, sunucu saatlerini daha uzun bir süreye, genelde birkaç saate yayarak yavaşlatıp veya hızlandırıp NIST’in bir yerlerindeki saf platinden, kusursuz küresel sarkaçlı duvar saatiyle yavaş yavaş yeniden hizalıyordu: https://developers.google.com/time/smear
  • time() ve clock_gettime(CLOCK_REALTIME) sonuçları artık saniyelerden etkilenir.
    Yeni artık saniye sisteme NTP üzerinden ulaşır. Ne yazık ki NTP yalnızca artık saniye uygulanacağını belirten bir bayrak dağıtır, ofsetin kendisini dağıtmaz. Ancak dağıtılan zamanın kendisi zaten artık saniyeden etkilendiği için NTP istemcisinin bunu mutlaka bilmesi gerekmez.
    Buna karşılık GPS ve PTP gibi diğer zaman eşitleme yöntemleri, artık saniyelerden etkilenmeyen bir zaman ölçeği kullanır ve UTC ofsetini ek bilgi olarak dağıtır. Alınan zamanı en sonda düzeltmek istemcinin görevidir. Çekirdekte artık saniyeler için clock_adjtime() parametresi vardır.
    NTP istemcisi olan elle yönetilen bir sistemde, yeni artık saniyeye göre zaman çalışma sırasında değişir. Linux, UTC zamanı öncelikli olarak ele alır; bu RTC aygıtına kaydedilir ve yeniden başlatmadan sonra da korunur.
    CLOCK_TAI TAI zamanını döndürmesi gerekiyormuş gibi görünür, ama sıradan Linux masaüstü ve sunucu dağıtımlarında ofset bile ayarlanmadığından CLOCK_REALTIME ile aynı zamanı döndürecek kadar ikinci sınıf muamele görür.
    /etc içinde, bir pakete dahil olan artık saniye listesi dosyası vardır; bu dosyayı güncellemek için sistem güncellemesi gerekir. Geleneksel NTP yazılımının bu paketi dinamik olarak güncellediğini sanmıyorum. Zaten bu dosyayı kullanan yazılım da pek fazla değildir.
    Eğer bir init servis betiği bunu ayrıştırıp çekirdeğin UTC ofsetini ayarlıyorsa, güncelleme yapılana kadar sistemin CLOCK_TAI değeri dünyanın geri kalanından 1 saniye geride olabilir. Ancak bildiğim kadarıyla bunun Linux’un UTC zamanı üzerinde herhangi bir etkisi yok.

• “Zamanın ölçümü ve dağıtımından sorumlu kurumlara” ifadesi gelmiş geçmiş en iyi resmî yazı girişlerinden biri

  • Daha da güzeli, o kuruluşun adının International Earth Rotation Service olması
  • USNO’da yıllar boyunca çeşitli hassas zaman ürünlerinden sorumlu liderlik unvanı “Director of the Directorate of Time” idi
  • Douglas Adams romanından çıkmış gibi bir ifade
  • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
    Unvanı bile bilimkurgu gibi

• UTC-TAI ofseti -37 saniyede kalırsa, bu UTC-GPS ofsetinin de -18 saniyede kalacağı anlamına gelir
  TAI ile GPS arasında sabit 19 saniyelik bir ofset var

• Böyle bir durumda Spanner gibi sistemlere ne olduğunu merak ediyorum
  Baş ağrısı mı, yoksa pek bir şey değil mi?

  • Büyük bir sorun. Bunu ele almanın en yaygın yöntemine smearing denir; “artık saniye”den önceki 24 saat boyunca her saniyenin uzunluğu ayarlanır
    Katı sıralama garantisi gerektiren sistemlerde her cihaz küresel saatle senkron kalır ve yalnızca saat tiklerinin uzunluğu çok az değiştiği için bu çalışır. Yanlış hatırlamıyorsam bu, özgün Spanner makalesinde de vardı
    Nadir bazı sistemler monoton osilatör saniyelerini kullanıp Dünya’nın dönüşüne dayalı saniyeleri yok sayar; ama bir gün bunu gerçek zamana dönüştürmeniz gerekiyorsa felaket zamanla birikir ve genelde iyi bir fikir sayılmaz
  • Artık saniyeler, artık günler gibi düzenli bir takvimle eklenmez; Dünya’nın fiziksel ölçümlerine bağlıdır
    Bu yüzden kapsamlı zaman yönetimi olan yüksek güvenilirlikli sistemlerin böyle bir seçimden çok sarsılmayacağını düşünüyorum

• Temporal API varsa tarayıcılar veya Node.js vb. o anın çevresindeki işlemlerde zamanı doğru işleyebilir mi? Yoksa hesapları bozmamak için güncelleme mi gerekir?

  • Temporal API, artık saniyeleri yok sayan Unix/POSIX zaman damgalarını temel alıyor gibi görünüyor. Unix zamanında bir gün her zaman 86400 “saniye”dir
    Bu yüzden veritabanı olmadan geçmiş ve gelecek UTC takvim hesapları kolayca yapılabilir; ayrıca kesirli saniyelerle uğraşmak da şart değildir. Artık saniyeler, işletim sisteminin 1 saniyeyi tekrarlaması veya atlaması ya da artık saniyenin öncesi/sonrası belirli bir süre boyunca saniyelerin uzunluğunu ayarlamasıyla ele alınır
    Çoğu tarih-saat API’si, temelde işlevsel/iş uygulamaları için takvim ve duvar saati işlemlerini destekleyecek şekilde tasarlanır. Bilimsel amaçlar için SI saniyelerine ihtiyacınız varsa, donanım düzeyine kadar gerekli anlamı sağlayan ve garanti eden ayrı API’ler ve özellikler kullanmalısınız
    Benzer şekilde, thread sleep gibi yazılım işlevleri için zamanlayıcı gerekiyorsa monoton saat gibi özel arayüzler kullanmalısınız. Artık saniyeler kademeli olarak ortadan kalksa da bu durum pek değişmez. Artık saniye düzeltmesi olsun ya da olmasın, örneğin bir mutex algoritmasının Unix zaman damgalarına dayanması eskiden de yanlıştı, gelecekte de yanlış olacak

• Beni bir dinleyin. Ekvatora jet motorları takıp 180 derece döndürerek zaman kazanır ya da kaybederiz. Sonra da bunu snooze düğmeme bağlarız

  • Superman’in Dünya’nın etrafında birkaç kez inanılmaz hızlı dönmesi daha kolay olmaz mı? Böylece motor bakımını dert etmeye gerek kalmaz
  • Aslında çok büyük miktarda suyu taşımak ölçülebilir bir etki yaratabilir. Örneğin California Central Valley akiferini tüketmek gibi
  • Sorun, gelecekteki toplumun o motorları yıldızlararası keşif gemileri için geri toplaması. Bu sorun Larry Niven’ın kitap serisinde ele alınmıştı
  • Hepimiz aynı anda zıplasak da olabilir gibi. Gereken sadece 1-2 saniye değil mi?
  • Bir süredir artık saniye eklemeye gerek kalmadığına göre bu yöntem işe yaramış gibi görünüyor

• “UTC ile TAI arasındaki fark 1 Ocak 2017 saat 0 UTC’den, ayrıca duyurulana kadar UTC-TAI = -37s” deniyor
  Bu, atom saatinin güneş saatinden 37 saniye geri kaldığı anlamına mı geliyor? 2017’den neden söz edildiğini de anlamıyorum

  • Aslında bunun tam tersine daha yakın
    UTC’de bir gün tam olarak 86400 SI saniyesi olarak tanımlanır. Ancak gerçek ortalama güneş günü birkaç milisaniye daha uzundur. Dünya’nın dönüşündeki düzensizlikler nedeniyle fark sabit değildir, ama ortalama farkın zamanla yavaş yavaş büyümesi beklenir. SI saniyesi atom saatleriyle sayıldığı için UTC, atom saatinin her 86400 saniyesinde bir günü geçirir
    Buna karşılık, ortalama güneş öğlene ulaştığında bir günü geçiren güneş saati, UTC’den birkaç milisaniye daha geç gün değiştirir. Gerçek güneşin yıl boyunca gökyüzünde ilerleme hızı değiştiğinden ortalama güneşi kullanmak gerekir
    Başka türlü söylersek, güneş saatinin tam 86400 saniye dediği her dönem, atom saati açısından birkaç milisaniye daha uzundur
    Bu durum her gün birikir ve neredeyse 1 saniyeye ulaştığında UTC’ye artık saniye eklenerek o gün 86400 değil 86401 saniye yapılır. Çünkü UTC yalnızca atom saati zamanını saymakla kalmaz; birçok insan etkinliği gökyüzündeki güneşin konumuyla ilişkili olduğundan güneşle de senkronize olmalıdır
    İnsanlar “güneşle senkronize” olmayı “ortalama güneşle 1 saniye içinde” diye tanımladı. Yani UTC öğleninin, başlangıç meridyenindeki ortalama güneş öğleninden en fazla 1 saniye farklı olmasını istiyoruz
    Dolayısıyla 37 saniye, artık saniyeler kullanılmasaydı ortalama güneş öğleninin UTC öğleninden ne kadar geride kalacağını ifade eder. UTC öğleniyken ortalama güneşin gökyüzünde başlangıç meridyeninden geçmesine hâlâ 37 saniye kalmış olurdu
  • Wikipedia’ya göre Aralık 2016, son artık saniyenin eklendiği zamandı: https://en.wikipedia.org/wiki/Leap_second
  • 2017’den söz edilmesinin nedeni, ofsetin en son o zaman değişmiş olmasıdır muhtemelen. Bu yüzden -37 saniye o zamandan beri geçerli durumda