Dünden daha eski öğelerde gerçek tarih gösterilmeli

• Web arayüzlerindeki göreli tarih etiketleri kulağa insani gelse de, kullanıcıların tarihleri zihninde canlandırma biçimiyle sık sık uyuşmaz
• İnsanlar için “yesterday”, bugünün bir önceki günü saat 00.00–23.59 aralığıdır; yalnızca “24 saatten az önce” anlamına gelmez
• Uygulamadan uygulamaya ölçütün değişmesi, aynı hizmet içinde bile “yesterday” gösteriminin tutarsızlaşmasına yol açarak tarih gösterimine duyulan güveni azaltır
• “12 days ago” gibi yalnızca sayıyla, kaç gün önce olduğunu uzun uzun gösteren ifadeler, insanların doğal zaman algısıyla örtüşmez
• “last week/month/year” da kapsamı geniş olduğu için belirsizdir; bu yüzden dünden daha eski öğeleri somut bir tarihle göstermek daha açıktır

---

Göreli tarih etiketleri neden kafa karıştırır?

• “yesterday”, “2 days ago”, “a week ago” gibi ifadeler insani zaman anlatımları gibi görünse de, gerçek tarihi anlamak için yeterince kesin değildir
• Özellikle “yesterday” ifadesinin kullanıcı açısından beklenen anlamı nettir
  • Bugünden bir önceki günü ifade eder
  • Önceki günün 00.00 ile 23.59 arasını kapsar
  • “24 saatten az önce” şeklindeki hesapla aynı şey değildir
• Bilgisayar uygulamaları “yesterday” ifadesini farklı şekillerde hesaplayabilir; aynı hizmet içinde bile gösterim değişirse kullanıcı tarih bilgisine daha az güvenir

Eski öğeleri tarihle göstermek daha iyidir

• “12 days ago” gibi ifadeler, insanların genelde düşündüğü zaman birimleriyle iyi örtüşmez
• “last week”, “last month”, “last year” ifadeleri de kapsamı geniş olduğu için belirsizlik taşır
• Dünden daha eski öğelerde göreli ifade yerine belirli bir tarih göstermek, hem okumayı hem de güvenmeyi kolaylaştırır

[cosine20]

Gerçekten GitHub da YouTube da "birkaç ay önce", "birkaç yıl önce" gibi şeyler yazınca çok sinir oluyorum. Aşağıdaki HN yorumlarında da var ama, "1 yıl önce" denilen şey aslında 1,5 yıl önce olabiliyor ve bu çok muğlak.

[budlebee]

Buna gerçekten katılıyorum. Geliştiren taraf açısından bakınca, X gün önce şeklinde gösterildiğinde YY.MM.DD mi yoksa mmddyyyy mi olacağı gibi ülkeye göre değişen tarih biçimlerini dert etmeye gerek kalmıyor ama ben X gün önce yerine tarihin gösterilmesini daha çok tercih ediyorum.

[GN⁺]

Hacker News yorumları

• Özellikle göreli zaman gösterimi çok fazla belirsizleşiyor.
  YouTube’da “1 yıl önce”, 365 gün öncesinden 729 gün öncesine kadar her şey anlamına gelebiliyor.
  “1 yıl önce” olarak görünen iki videodan hangisinin daha yeni olduğunu anlamak için, gerçekten videoyu açıp açıklama bölümüne kadar giderek tarihe bakmak gerekiyor.

  • Sanki UI tasarımcıları toplanıp kullanıcıları rahatsız etmeye yönelik bir GUI mikro-saldırı yarışması düzenlemiş, “N gün önce” trendi kazanmış ve her yere yayılmış gibi.
    Kafamda tarih hesabı yapmak istemiyorum; sadece kesin zaman damgasını gösterin yeter.
    “1 yıl önce” gibi geniş aralıklı bir ifadeyle bilgiyi çöpe atmak yerine gerçek zamanı göstermeleri gerekiyor.
  • Daha da ilginç olan, her sitenin yuvarlama ölçütünün farklı olması.
    YouTube’daki “1 yıl önce” 365~729 gün öncesi olabilirken, bazı sitelerde en yakın yıl birimine yuvarlama yapıldığı için 183~548 gün öncesi anlamına geliyor; bazı siteler de 11 aya kadar ay birimine yuvarlayıp 350~548 gün öncesini “1 yıl önce” sayıyor.
    Başka yerlerde ise “geçen takvim yılı içinde” gibi ölçütlerle 1~365 gün öncesinden 364~729 gün öncesine kadar bile mümkün hale geliyor.
  • Şu an Ekim 2023 ise, Kasım 2021’de yüklenen bir video “1 yıl önce” diye görünmemeli; “neredeyse 2 yıl önce” olmalı.
  • Aynı tarih olsa bile saat daha geçse aşağı yuvarlanıyor.
    14 Ekim 2021’de yüklenen bir video 2 yıl önce olsa bile, o gün daha geç bir saatte yüklendiyse hâlâ 1 yıl önce diye gösterilebilir.
  • İlk sayının 1 olmamasını sağlayıp daha küçük birime geçilirse belirsizlik azaltılabilir.
    Örneğin 120 saniye öncesine kadar, 120 dakika öncesine kadar, 48 saat öncesine kadar, yaklaşık 61 gün öncesine kadar, ardından da 24 ay öncesine kadar göstermek gibi.
    Listelerdeki göreli tarihler genelde katlanılabilir ama güncellenmeme sorunu çok daha sinir bozucu; bunu “dün” ile sınırlamak da çözmez.

• Bunu daha güçlü şekilde önermek isterim.
  Neyse ki zaman damgasının araç ipucunda göründüğü durumlar çok.
  Örneğin bir npm paket sürümüne bakarken “version 5.3.27 was released ‘about a year ago’” gibi bir ifade çıkıyor; insan aklından şüphe ediyor.
  Eski paketlerin yayımlanma sırasını anlayıp uyumlu bir sabitleme kombinasyonu oluşturmaya çalışıyorum, ama art arda 20 paketin tamamı “yaklaşık 1 yıl önce” diye göründüğü için her biri için araç ipucunu açıp yeni sürüm olup olmadığını kontrol etmem gerekiyor.
  Bu tür bir tasarım sınırı aşıyor; düzensiz tekil/çoğul tablo adlarını eşleyen ORM yapan insanlarla aynı türden görünüyor.

  • Gerçekten YouTube’da da araç ipucu varmış.
    Neden bilmediğimi bilmiyorum; oldukça kullanışlıymış.
  • Aklından şüphe edilecek bir durum değil; sadece aptallık ya da iyimser bakarsak beceriksizlik derecesinde cehalet.
  • Geliştirici araçlarında böyle şeyler yapan insanlar suç sayılacak düzeyde beceriksiz.
    Şaşırtıcı olan, bu kişilerin hâlâ istihdam ediliyor olması bir yana, bu aptal yöntemin npm’den GitHub’a, CircleCI’a kadar her yere yayılmış olması.

• Daha da ileri gidip bu tür yuvarlanmış göreli zaman damgalarını tamamen kaldırmak istiyorum.
  iOS Mail uygulaması özellikle sinir bozucu.
  Açınca “az önce güncellendi” diyor, ama aşağı çekip yenileyince 2 saat önce gelen okunmamış bir e-posta birden ortaya çıkıyor.
  Sadece ne zaman güncellendiğini kesin saat olarak göstersin yeter.

  • Bildirimlerdeki aptal zaman damgaları daha da kötü.
    Bir saat içinde göremezsen hemen belirsizleşiyor; yalnızca “1 saat önce” mi “2 saat önce” mi olduğunu görüyorsun.
    Bir bildirimin tam olarak ne zaman geldiğini bilmen gerekebilir, ama bunu kontrol etmenin hiçbir yolu yok.
    Sadece saati göstersinler; saati okuyabiliyorum.
  • Thunderbird’ün iyi yanlarından biri, hâlâ kesin tarih ve saati göstermesi.
    Bugünse yalnızca saati, diğer durumlarda tam tarih ve saati gösteriyor.

• Mutlak zaman kullanılırsa tarayıcı bunu kullanıcının tercih ettiği biçime göre gösterebilir.
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...

  • Sunucunun yalnızca veriyi gönderdiği, istemcinin de gösterim biçimini seçtiği web hayali tamamen öldü.
    Web tasarımcıları sitenin piksel düzeyine kadar belirli bir görünüme sahip olmasını istiyor; istemci tarafındaki gösterim denetimi de buna engel oluyor.
    Hâlâ yapılabilir, ama web siteleri böyle bir kullanım düşünülerek tasarlanmayacak ya da buna aktif olarak yardımcı olmayacak.
  • Ortalama kullanıcının gerçekte nasıl bir görünüm göreceğinden emin değilim.
    Örnekte iOS/Safari çıktısı, etiket yokmuş gibi görünüyor.

• Belirsiz tarih gösteriminde özellikle rahatsız edici olan, haftanın gününün en önemli bilgi olduğu durumlar
  Örneğin GitLab geçmişine bakarken bir şeyin “geçen hafta” ya da “2 gün önce” değil, cuma günü birleştirilip birleştirilmediğini bilmek çok daha kullanışlıdır
  Sohbet kayıtlarında da ay sınırına yakınsa konuşmanın ay başından önce mi sonra mı olduğu önemli olabilir
  Diğer durumlarda da kişisel olarak 4 hafta önce mi 2 ay önce mi olduğundansa kesin tarihi tercih ederim; kesin tarih vermek bilgiyi azaltmaz da
  Belirsiz bir tarihin kesin tarihten daha kullanışlı olduğu bir durumu hayal etmek zor

  • GitLab ekibinin bir üyesiyim
    GitLab’da ayarı değiştirirseniz göreli zaman yerine mutlak zaman kullanabilirsiniz
    Örnek: October 14, 2023 11:51AM
    https://docs.gitlab.com/ee/user/profile/preferences.html#sho...
  • Jira’nın işe yaramaz zaman etiketlerini haftanın gününü içeren tam tarihe çeviren bir Greasemonkey betiği yaptım
    Sık kullandığınız tarayıcı tabanlı yazılımlarda böyle şeyler uygulamanızı şiddetle öneririm
  • Çok özel durumlarda belirsiz tarihler kullanışlı olabilir
    Başka bir veritabanından bilgi alıp yeniden biçimlendirerek kullanıcıya gösteren bir uygulama var; güncellemenin maliyeti yüksek ve uzun sürdüğü için kullanıcı gerektiğinde bunu elle çalıştırmak zorunda
    Bu durumda son güncellemenin kesin saati pek önemli değil; önemli olan verinin ne kadar eski olduğu, yani kaynakla uyuşmama olasılığının ne kadar olduğu
    Bazı bilgilerin birkaç saat sonra yenilenmesi gerekirken, bazı bilgiler 4-5 günden fazla eski olsa bile sorun olmaz; dolayısıyla 10 dakikaya kadar sürebilen bir güncellemeye gerek yoktur
    Bu amaç için son güncelleme saatinden çok yaklaşık eskiliği göstermek daha kullanışlıdır; kullanıcı da mevcut saatle karşılaştırıp hesap yapmak zorunda kalmaz
    Yine de bu nadir bir örnek; çoğu durumda göreli belirsiz tarihler daha az kullanışlıdır
  • Farklı saat dilimlerindeki insanlara yakın gelecekteki zamanları iletirken göreli zaman kullanışlıdır
    “Bu yorumdan yaklaşık 4-5 saat sonra bitiyor”, “düzeltildi ve bir sonraki çalıştırmayı bu yorumdan yaklaşık 15 saat sonra başlatıyor” gibi

• Zaman damgalarını kötü gösteren, kullandıklarım arasındaki en kötü uygulama gitg
  Şu ekran görüntüsüne bakmanız yeterli
  https://ubunlog.com/wp-content/uploads/2018/06/git-gui-gitg....
  Birden çok commit “3 gün önce” diye gösteriliyor; bu, hiç bilgi olmamasından ancak biraz daha iyi
  Sabah mı öğleden sonra mıydı, bir saat içine mi sıkışmışlardı yoksa tüm güne mi yayılmışlardı, bilemiyorsunuz
  Bir müşteri için çalışma saatlerini kaydetmeyi unutup bir hafta sonra hesaplamak zorunda kaldığınızda bu tür bilgiler önemlidir; bu yüzden commit’lere tek tek tıklayıp ekranın karşı tarafındaki zaman damgasını kontrol etmek zorunda kalırsınız

  • Ekran görüntüsü, tam tarih gösteriminin her zaman gerekli olmasının önemli nedenlerinden biri
  • Outlook webmail de epey kötü
    Sadece “birkaç gün önce” göstermekle kalmıyor, önemli olduğuna karar verdiği öğeleri en üste çıkarmaya da çalışıyor
    Böylece kısmen çakışan iki liste birbirine karışıyor ve berbatlık ikiye katlanıyor
  • git zaman damgaları her geliştiricinin yerel saat dilimine göre ayarlanır ve doğrulanmaz; bu da küresel geliştirmede işi daha da zorlaştırabilir
    https://alesnosek.com/blog/2017/01/02/git-getting-the-timing...
  • gitg’de her zaman tam tarih ve saat gösterecek bir ayar bulunmuyor gibi görünmesi şaşırtıcı
  • Ekran görüntüsündeki gösterim biçimi, sektörel bir düzenleyici kurum olsaydı mesleki görev ihlali adayı olurdu

• İkisini de göstermek yeterli
  “1 saat önce (15:47)”
  “geçen hafta (MON 12 SEP 9:20)”
  “2 yıl önce (WED 14 APR 2021 11:47)”
  Tarih biçimi zevkinize kalmış

  • Frontend’de sayfada göreli zamanı render edip tooltip’e gerçek zaman damgasını ya da tarih biçimini koymak kullanışlı olmuştu
    Daha ayrıntılı görmek isteyen göreli tarihin üzerine fareyle gelebilir
  • Eskiden “ihtiyacı olan kullanıcı UI’ı aşırı yüklemeden bunu bulabilir” diye düşünerek kesin saat ve tarih bilgisini tooltip’e koyuyorduk
    Yıllar sonra kullanıcı görüşmelerinde, hyperlink tarzı alt çizginin tek başına kullanıcıya “buraya fareyle gelmeliyim” dedirtmediği ortaya çıktı; bu yüzden bunun çoğunu geri aldık
    Emoji ve yüksek çözünürlüklü ekranların yaygınlaştığı bugünlerde, göze batan bir soru işareti ya da büyüteç görseliyle tooltip ipucu vermenin daha yaşlı veya daha az deneyimli kullanıcılar için yeterli olup olmayacağını merak ediyorum
  • Neden sadece tarihi göstermiyoruz ki?

• Yıl da dahil edilmeli
  Web forumlarının yorum tarihini yalnızca “5 Jul” gibi göstermesi yüzünden, o yorumun yıllar öncesine ait olduğunu sonradan fark ettiğim çok oldu
  Artık yılsız tarihlere güvenmiyorum; en baştan görünmüyorsa yılı bir şekilde bulmaya çalışıyorum

  • Yıl 4 haneli yazılmalı
    Haftada birkaç kez gittiğim bir forum var; 20-30 yıllık bir yer, tarihler 08/11/02, 09/03/04 gibi basılıyor ve bu çok kafa karıştırıcı

• “1 yıl önce” yeterince kesin olmayabilir ama “11 ay önce” çoğu zaman yeterlidir
  Böyle bir işlevi uygularken 1 sayısından kaçınmayı tercih ederim
  “1 hafta önce” yerine “6 gün önce” göstermek gibi

• Google veya web.archive.org gibi yerlerde saklandığında, etiket istemci tarafında hesaplanmıyorsa indeksleme tarihine göre göreli zaman haline gelebilir
  Arşivlerde JavaScript’in de düzgün çalışmama olasılığı yüksek
  Ayrıca tarihleri daha erişilebilir göstermek için time etiketi ve datetime niteliğini kullanmayı düşünmek de iyi olabilir
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ti...
  Tarayıcılarda şimdilik span etiketinden pek farklı değil, ama web sayfasını geleceğe uyumlu yapmakta zarar yok