Planlama uygulamalarında zaman dilimleri: kullanıcı öfkesini önleyen kurallar

Neden zaman dilimleri planlama uygulamalarını güvenilmez hissettirir

Zaman dilimleri küçük matematik hatalarını boşa çıkan sözlere dönüştürür. Bir toplantının 1 saat kayması "yaklaşık doğru" sayılmaz. Kimlerin katıldığı, kimlerin hazırlıksız göründüğü ve kimin önemli bir şeyi kaçırdığı değişir. Bu iki kez olursa insanlar takvimlerine güvenmeyi bırakır ve her şeyi sohbette iki kere kontrol etmeye başlar.

Sorunun kökü: insanlar zamanın mutlak olduğunu düşünür, ama yazılımda öyle değildir. İnsanlar yerel saatle düşünür ("saat benim zamanımda 09:00"). Bilgisayarlar genellikle yıl içinde değişebilen offsetlerle ("UTC+2") düşünür. Uygulamanız bu fikirleri karıştırdığında, bugünkü doğru saat sonraki ay yanlış olabilir.

Belirtiler de rastgele göründüğü için işler daha da kötü olur. Kullanıcılar şöyle şeyler bildirir: toplantıların "hareket ettiği" (kimse düzenlemediği halde), hatırlatmaların erken veya geç tetiklendiği, serinin sadece bazı örneklerinin 1 saat kaydığı, davetlerin farklı cihazlarda farklı saat gösterdiği veya seyahatten sonra çoğaltılmış etkinliklerin göründüğü.

En çok etkilenenler, planlamaya en çok güvendikleri kişiler olur: birçok ülkede çalışan uzak ekipler, sınır ötesi rezervasyon yapan müşteriler ve seyahat eden herkes. New York'tan Londra'ya uçan bir ürün yöneticisi 14:00 toplantısının organizatörün zaman dilimine sabit kalmasını bekleyebilir; yolcu ise toplantının kendi bulunduğu yerel zamana göre takip etmesini bekleyebilir. Her iki beklenti de mantıklıdır. Sadece biri doğru olabilir, bu yüzden açık kurallara ihtiyacınız var.

Bu sadece etkinlik kartında gösterdiğiniz saatin ne olduğu meselesi değil. Zaman dilimi kuralları tek seferlik etkinlikleri, tekrarlayan etkinlikleri, hatırlatmaları, davet e-postalarını ve belirli bir anda tetiklenen her şeyi etkiler. Bu öğeler için kural tanımlamazsanız, veri modeliniz sizin için sessizce bir kural tanımlar ve kullanıcılar bunu zor yoldan keşfeder.

Basit bir örnek: Mart'ta oluşturulmuş haftalık "Pazartesi 09:00" standup'ı olsun. Nisan'da bir katılımcının bölgesinde DST değişirse, uygulamanız bunu "her 7 günde aynı UTC anında" sakladıysa o katılımcı aniden 10:00'da görür. Uygulamanız bunu "organizasyonun zaman diliminde her Pazartesi 09:00" olarak sakladıysa 09:00'da kalır ve UTC anı değişir. Her iki seçim de işe yarayabilir, ama uygulama tutarlı ve dürüst olmalıdır.

Temel terimler: UTC, yerel saat, offsetler ve DST

Çoğu zaman dilimi hatası birkaç temel fikri karıştırmaktan kaynaklanır. Doğru kelimeleri kullanmak ayrıca kullanıcı arayüzü metinlerinizi de netleştirir.

UTC ve "mutlak zaman"

UTC (Coordinated Universal Time) küresel referans saatidir. Herkesin paylaştığı tek zaman çizgisi olarak düşünebilirsiniz.

Bir "mutlak zaman" o zaman çizgisindeki belirli bir andır, örneğin 2026-01-16 15:00:00 UTC. Farklı ülkelerdeki iki kişi o ana baktığında aynı anı görmeli, sadece farklı yerel saatlerle görüntülenmelidir.

Yerel saat, offsetler ve zaman dilimi kimlikleri

Yerel saat duvardaki saatinizdir, örneğin "09:00". Kendi başına bu bir anı tanımlamak için yeterli değildir. Bir konum kuralına ihtiyacınız vardır.

Offset, bir andaki UTC farkıdır, örneğin UTC+2 veya UTC-5. Pek çok yerde offsetler yıl içinde değişir, bu yüzden sadece "UTC+2" saklamak risklidir.

Zaman dilimi kimliği gerçek kural setidir, genellikle IANA adıyla olur: America/New_York veya Europe/Berlin gibi. Kimlikler o bölgenin geçmişini ve gelecekteki değişikliklerini, DST de dahil olmak üzere yakalar.

Pratik fark:

• Offset: "UTC-5" (bundan sonra aynı kalacağına dair söz vermez)
• Zaman dilimi kimliği: "America/New_York" (ne zaman UTC-4 olacağını bilir)

DST (yaz saati uygulaması)

DST, bir bölgenin saatleri genellikle bir saat ileri veya geri almasıdır. Bu, UTC offsetinin değişmesi demektir.

İki DST sürprizi:

• "Bahar ileri" saat kaydırması bir saatin kaybolmasına yol açar. Bazı yerel saatler hiç var olmaz.
• "Sonbahar geri" tekrar eden bir saat yaratır. Aynı yerel saat iki kez gerçekleşir.

Mutlak zaman vs duvardaki saat

Duvardaki saat kullanıcıların yazdığı şeydir: "Her Pazartesi 09:00". Mutlak zaman ise sisteminizin yürütmesi gereken şeydir: "bu kesin UTC anında hatırlatmayı gönder". Tekrarlayan etkinlikler genellikle duvar saati kuralları olarak başlar, sonra bir dizi mutlak zamana dönüştürülür.

Kullanıcılar "zaman dilimimde 09:00 rezervasyon yaptım" diye düşünür. Veritabanınız 2026-03-10 13:00 UTC saklamış olabilir. Her ikisi de doğru olabilir ama niyetin hangi zaman dilimi kurallarıyla alındığını da hatırlamanız gerekir.

Cihazlar da zaman dilimlerini değiştirir. İnsanlar seyahat eder ve dizüstü bilgisayarlar otomatik olarak bölgelerini değiştirebilir. Uygulamanız kaydedilmiş "09:00"u cihazın yeni bölgesine göre sessizce yeniden yorumlarsa, kullanıcılar toplantının "taşındığını" hisseder.

Sessiz zaman kaymalarını önleyen veri modeli seçimleri

Çoğu "toplantım hareket etti" hatası veri modeli hatasıdır. Tek seferlik etkinlikler için en güvenli varsayılan: tek bir UTC anını saklayın ve yalnızca gösterirken kullanıcının yerel zamanına çevirin.

Tek seferlik bir etkinlik örneği: "12 Eki 2026, Berlin'de 15:00." O an bir kere olur. UTC (zaman çizgisindeki bir an) olarak saklarsanız, görüntüleyen nerede olursa olsun aynı ana geri eşlenir.

Sadece yerel saati saklamak (örneğin "15:00") biri farklı bir zaman diliminden bakınca veya oluşturucunun cihaz ayarı değiştiğinde bozulur. Sadece offset saklamak (örneğin "+02:00") daha sonra bozulur çünkü offsetler DST ile değişir. "+02:00" bir yer değil, geçici bir kuraldır.

Ne zaman UTC ile birlikte bir zaman dilimi kimliği saklamalısınız? Oluşturucunun ne demek istediğini önemsiyorsanız, sadece hangi anı sakladığınız değil. Europe/Berlin gibi bir zone ID, gösterim, denetim ve destek için yardımcı olur ve tekrarlayan etkinliklerde vazgeçilmezdir. "Bu etkinlik Berlin saatine göre 15:00 olarak oluşturuldu" diyebilmenizi sağlar, Berlin'in offseti gelecek ay değişse bile.

Tek seferlik bir etkinlik için pratik bir kayıt genellikle şunları içerir:

• start_at_utc (ve end_at_utc)
• created_at_utc
• creator_time_zone_id (IANA adı)
• original_input (kullanıcının girdiği metin veya alanlar)
• input_offset_minutes (isteğe bağlı, hata ayıklama için)

Destek için bu alanlar, belirsiz bir şikayeti net bir tekrar oynatmaya çevirir: kullanıcının ne yazdığı, cihazın iddia ettiği zon ve sisteminizin sakladığı an.

Dönüştürmenin nerede yapıldığına katı davranın. Depolama için sunucuyu (sadece UTC) kaynak olarak görün ve istemciyi niyetin kaynağı (yerel saat artı zaman dilimi ID) olarak görün. Yerel zamanı UTC'ye oluşturma veya düzenleme anında bir kere dönüştürün ve saklanan UTC'yi sonraki okumalarda "yeniden-dönüştürmeyin". Sessiz kaymalar genellikle hem istemci hem sunucu dönüşüm uyguladığında ya da bir taraf sağlanan zaman dilimini kullanmayıp tahmin ettiğinde olur.

Birden fazla istemciden etkinlik kabul ediyorsanız, zaman dilimi ID'sini kaydedin ve doğrulayın. Eksikse tahmin etmek yerine kullanıcıya seçtirmeyi isteyin. Bu küçük uyarı daha sonra gelen birçok sinirli bileti önler.

Adım adım: kullanıcı girdisinden saklanan etkinliğe ve gösterime

Kullanıcılar zamanların "hareket ettiğini" görmeye devam ettiğinde genellikle sistemin farklı parçaları zamanları farklı yollarla dönüştürür.

Dönüştürmeler için bir kaynak yeri seçin. Birçok ekip sunucuyu seçer çünkü web, mobil, e-posta ve arka plan işleri için aynı sonucu garanti eder. İstemci önizleme yapabilir, ama sunucu nihai saklanan değerleri onaylamalıdır.

Uygulanabilir ve güvenli bir akış

Yineleyebilir bir boru hattı çoğu sürprizi önler:

• Kullanıcı girişi: kullanıcının yazdığı duvar saatini yakalayın (örneğin 2026-03-10 09:00) ve etkinlik zaman dilimini IANA adıyla (America/New_York) alın, "EST" gibi kısaltmalar yerine.
• Normalizasyon: duvar saatinin o zon içinde var olup olmadığını doğrulayın (DST bazı zamanları yok edebilir), sonra bir an'a dönüştürün.
• Sakla: anı UTC olarak ve IANA zon ID'sini (ve gerekirse kullanıcının seçtiği orijinal duvar saatini) kaydedin.
• Görüntüle: saklı UTC anını görüntüleyen kişinin mevcut zonuna çevirin ve açıkça etiketleyin ("09:00 New York saati").
• Bildirim: hatırlatmaları UTC anından planlayın, ama mesajı alıcının yerel zamanında formatlayın.

Örnek: New York'ta bir ev sahibi "Sal 09:00 (America/New_York)" oluşturur. Berlin'deki bir takım arkadaşı bunu kendi zonunda "15:00 (Europe/Berlin)" olarak görür çünkü aynı UTC anı onların zonuna çevrilmiştir.

Tüm gün etkinlikleri ve sadece tarih alanları

Tüm gün demek "00:00 UTC'den 00:00 UTC'ye" değildir. Genellikle belirli bir zaman diliminde bir tarih aralığıdır. Tüm gün etkinliklerini tarih-only değerleri (start_date, end_date) ve bu tarihlerin yorumlandığı zon ile saklayın. Aksi takdirde, tüm gün etkinliği UTC'den batıda kalan kullanıcılar için bir önceki gün başlamış gibi görünebilir.

Yayınlamadan önce gerçek dünya senaryosunu test edin: bir etkinlik oluşturun, cihaz zaman dilimini değiştirin, sonra tekrar açın. Etkinlik aynı anı (zamanlı etkinlikler için) veya aynı yerel tarihi (tüm gün etkinlikleri için) temsil etmeli, sessizce kaymamalıdır.

Tekrarlayan etkinlikler: şemayı seçmeden önce kuralı seçin

Çoğu planlama hatası bir etkinlik tekrar ettiğinde ortaya çıkar. Yaygın hata tekrarı "tarihi ileri yapıştırmak" olarak görmek. İlk önce etkinliğin neye sabitlendiğine karar verin:

• Bir ana an'a sabitlenmiş: etkinlik aynı anda (aynı UTC anı) tekrarlanır, bu yüzden yerel saat DST değiştiğinde değişebilir.
• Yerel duvar saatine sabitlenmiş: etkinlik belirli bir zaman diliminde aynı yerel saatte tekrar eder, UTC anı değişse bile.

Çoğu takvim için (toplantılar, hatırlatmalar, çalışma saatleri) kullanıcılar duvar saatini bekler. "Her Pazartesi 09:00" genellikle seçilen şehirde 09:00 demektir, "hep aynı UTC anı" değil.

Ne saklamalıyız (sonra açıklayabilmek için)

Tekrarlamayı, önceden üretilmiş zaman damtalarından ziyade onu yorumlamak için gereken bağlamla birlikte bir kural olarak saklayın:

• Başlangıç yerel tarih ve saat (kullanıcının yazdığı)
• Zaman dilimi ID (IANA)
• Tekrar kuralı (frekans, aralık, günler)
• İstisnalar (atlamalar, tek örneklere yapılan düzenlemeler)
• İsteğe bağlı bitiş koşulu (adet veya kadar tarih, yerel terimlerle)

Bu, DST ile başa çıkmanıza yardımcı olur ve düzenlemeleri öngörülebilir kılar.

Örnekler üretirken sürüklenmeyi önleme

Belirli bir tarih aralığı için etkinliklere ihtiyacınız olduğunda, etkinliğin zonunda yerel saatte üretip sonra her örneği karşılaştırma veya saklama için UTC'ye çevirin. Anahtar nokta, yerel terimlerle "bir hafta ekle" veya "gelecek Pazartesi" demektir, UTC'de "+7 * 24 saat" eklemek değil.

Basit bir zihinsel test: kullanıcı Berlin'de haftalık 09:00 seçtiyse, üretilen her örnek Berlin saatinde 09:00 olmalıdır. Berlin DST değiştiğinde UTC değeri değişecek ve bu doğrudur.

Kullanıcılar seyahat ettiğinde, davranış hakkında açık olun. Berlin'e sabitlenmiş bir etkinlik Berlin saatinde 09:00'da gerçekleşmeli; New York'ta olan bir yolcu bunu kendi yerel saatine çevrilmiş olarak görür. İzleyicinin mevcut zaman dilimini takip eden "yüzen" etkinlikleri destekliyorsanız, bunu net şekilde etiketleyin. Kullanışlıdır, ama belirtilmediğinde insanları şaşırtır.

En çok sinirli bilet yaratan DST tuzakları

DST sorunları kullanıcılarda rastgele hissi uyandırır çünkü uygulama rezervasyon sırasında bir saat gösterir, sonra daha sonra farklı bir saat gösterir. Düzeltme sadece teknik değildir. Net kurallara ve net kelimelere ihtiyacınız var.

Saatler ileri alındığında bazı yerel saatler hiç yoktur. Klasik örnek DST başlama gününde 02:30'dur. Birinin bunu seçmesine izin verirseniz ne anlama geldiğine karar vermelisiniz.

Saatler geri alındığında ise aynı yerel saat iki kez olur. "01:30" ilk (kaydırma öncesi) veya ikinci (kaydırma sonrası) anlamına gelebilir. Sormazsanız tahmin yapıyorsunuz demektir ve insanlar toplantıya bir saat erken veya geç katıldıklarında fark ederler.

Sürprizleri önleyen pratik kurallar:

• Seçilen zaman yoksa (bahar ileri), bunu engelleyin ve nedenini açıklayın veya otomatik olarak bir sonraki geçerli zamana taşıyın ve değişikliği hemen gösterin.
• Seçilen zaman çiftlenmişse (sonbahar geri), "Hangi 01:30?" diye sorun ve seçenekleri offset ile "daha erken" ve "daha geç" şeklinde etiketleyin.
• Var olan bir toplantı zaman dilimi güncellemesi nedeniyle geçersiz hale gelirse, mümkünse özgün niyeti koruyun ve kaydırmanız gerekiyorsa bildirim gönderin.
• Hatırlatmalar için, hatırlatmayı duvar saatinden "N dakika önce" değil etkinliğin gerçek anına göre planlayın.
• Asla bunu kullanıcı hatası gibi ifade etmeyin. Bunu ilgili yerde saat değişikliği olarak çerçeveleyin.

Gerçekçi bir destek bileti başlangıcı: biri gelecek ay için New York'ta "02:30" rezervasyonu yapar, sonra gün gelip uygulama sessizce "03:30" gösterir. Oluşturma zamanında daha iyi bir metin basittir: "Bu saat 10 Mar'da saat değişikliği nedeniyle mevcut değil. 01:30 veya 03:00 seçin." Otomatik ayarlıyorsanız söyleyin: "02:30 olmadığı için 03:00'a taşıdık."

DST'i bir UI kenar durumu olarak görürseniz, bu bir güven problemi olur. Bunu bir ürün kuralı olarak ele alırsanız, öngörülebilir olur.

Kaçınılması gereken yaygın hatalar ve tuzaklar

Çoğu sinirli bilet birkaç tekrar eden hatadan gelir. Uygulama "saati değiştiriyor" gibi görünür, ama gerçek sorun veride, kodda ve metinde kuralların açıkça konmamış olmasıdır.

Veri ve saklama tuzakları

Yaygın bir hata sadece offset ("-05:00") saklamak yerine gerçek bir IANA zaman dilimi (America/New_York) saklamamaktır. Offsetler DST başladığında veya bittiğinde değişir, bu yüzden Mart'ta doğru görünen bir etkinlik Kasım'da yanlış olabilir.

Zaman dilimi kısaltmaları da sık hatalara yol açar. "EST" farklı insanlar ve sistemler için farklı anlamlar taşıyabilir ve bazı platformlar kısaltmaları tutarsız eşler. Tam bir zaman dilimi ID'si saklayın ve kısaltmaları yalnızca gösterim amaçlı metin olsun; gösteriyorsanız bile.

Tüm gün etkinlikleri ayrı bir kategoridir. Bir tüm gün etkinliğini "00:00 UTC" olarak saklarsanız negatif offsetteki kullanıcılar bunu bir önceki gün başlamış olarak görür. Tüm gün etkinliklerini tarihler ve bu tarihler yorumlanırken kullanılan zon ile saklayın.

Kod incelemesi için kısa bir kontrol listesi:

• Offset-only zamanlar saklamayın ve DST'in çalışmasını beklemeyin.
• "EST/PST/CET" gibi kısaltmaları güvenilir zon kabul etmeyin.
• Tüm gün etkinliklerini anlar (00:00 UTC) olarak saklamayın.
• Hatırlatmaları sunucunun zonunda değil etkinliğin zonunda planlayın.
• Web ve mobilin dönüşümleri farklı hesaplamasına izin vermeyin.

Teslimat, hatırlatmalar ve çapraz platform uyumsuzlukları

Etkinlik saklaması doğru olsa bile hatırlatmalar ve davetler yanlış gidebilir. Örnek: kullanıcı "09:00 Berlin saati" oluşturur ve Berlin için 08:45 hatırlatması bekler. İş zamanlayıcınız UTC'de çalışıp yanlışlıkla "08:45"i sunucu yerel saati olarak ele alırsa hatırlatmalar erken veya geç çalışır.

Çapraz platform farklılıkları bunu daha da kötüleştirir. Bir istemci belirsiz bir zamanı cihaz zonunu kullanarak yorumlarken, diğeri etkinlik zonunu, üçüncüsü cached bir DST kuralını uygulayabilir. Tutarlı davranış istiyorsanız dönüşümleri ve tekrar genişletmeyi tek yerde (genellikle sunucu) tutun ki her istemci aynı sonucu görsün.

Basit bir akıl testi: DST değişiminin olduğu hafta içinde bir etkinlik oluşturun, iki farklı zone ayarlı cihazda görüntüleyin ve başlangıç saati, tarih ve hatırlatma zamanının vaat ettiğiniz kuralla eşleştiğini doğrulayın.

Özellikleri yayına almadan önce hızlı kontroller

Çoğu zaman dilimi hatası geliştirme sırasında hata gibi görünmez. Birisi seyahat ettiğinde, DST değiştiğinde veya iki kişi ekran görüntülerini karşılaştırdığında ortaya çıkar.

Veri ve saklama kontrolleri

Veri modelinizin ele aldığınız zaman tipine uygun olduğundan emin olun. Tek seferlik bir etkinlik tek bir gerçek an gerektirir. Tekrarlayan etkinlik yerle bağlı bir kurala ihtiyaç duyar.

• Tek seferlik etkinlikler için kesin bir an (UTC) saklayın ve kullanıcıya "ne seçtiğini" göstermeniz gerekiyorsa orijinal bağlamı da saklayın.
• Tekrarlayan veya kullanıcıya gösterilen her şey için IANA zaman dilimi ID'sini saklayın (örneğin America/New_York), sadece offset değil.
• "Yüzen" ("her gün 09:00" belirli bir zon içinde) zamanlar ile anlar (2026-01-16T14:00Z) arasında net ayrım yapın.

DST ve kenar durum kontrolleri

DST iki tehlikeli an oluşturur: var olmayan zamanlar (bahar ileri) ve iki kez olan zamanlar (sonbahar geri). Uygulamanız ne yapacağına karar vermeli ve tutarlı olmalıdır.

• Kullanıcı var olmayan yerel zamanı seçerse bunu temiz bir mesajla engelleyin veya otomatik olarak bir sonraki geçerli zamana kaydırın (ve söyleyin).
• Kullanıcı belirsiz zamanı seçerse (çiftlenen saat), hangi olanı istediğini seçmesini isteyin veya bir kural belirleyip belgeleyin.
• Tekrarlayan etkinlikleri DST sınırları boyunca doğrulayın. "Yerel 09:00"un 09:00 olarak kalıp kalmayacağına veya UTC zamanının sabit kalıp kalmayacağına karar verin. Birini seçin ve uygulayın.

Test senaryosu: Berlin'de "Pazartesi 09:00" olarak ayarlanmış haftalık takım senkronizasyonu. Bu toplantının New York'ta nasıl göründüğünü, Avrupa DST değişmeden önce, sonra ve ABD DST değiştikten sonra kontrol edin (farklı tarihlerde değişirler).

UI ve beklenti kontrolleri

Birçok sinirli bilet zaman dilimini gizleyen arayüzlerden gelir. İnsanlar istediklerini varsayar.

• Bir saatin göründüğü her yerde zaman dilimini gösterin: etkinlik detayları, onay ekranları, e-postalar, hatırlatmalar ve dışa aktarmalar.
• Başkası adına planlıyorsanız her iki zonu gösterin: "09:00 Europe/Berlin (03:00 America/New_York)".
• Zaman dilimi kontrollerini belirgin yapın ve seçilen zonu metinde yansıtın ("Bu etkinlik Europe/Berlin zamanına kaydedildi").

Test kontrolleri

Kendi laptop'unuzun zonuna ve tek bir yerel formata güvenmeyin.

• Seyahat senaryoları için testler ekleyin: bir zonda etkinlik oluşturun, sonra başka bir zonda görüntüleyin.
• DST başlangıç ve bitişini kapsayan testler ekleyin; kaybolan ve tekrarlanan saatleri dahil edin.
• Farklı yerel formatlarda test edin (12 saat vs 24 saat, gün-ay vs ay-gün) "yanlış gün" raporlarını önlemek için.

Gerçekçi bir örnek: bir toplantı, iki ülke, bir DST değişikliği

Londra merkezli bir kurucu, New York'taki bir takım arkadaşıyla haftalık standup planlar. "Salı 10:00" seçerler ve bunun her zaman Londra için sabah, New York için erken saat gibi kalacağını varsayarlar.

Daha güvenli bir yaklaşım: toplantıyı "her Salı 10:00 Europe/London'da" olarak ele almak, her örneği London zamanında hesaplamak, o örnek için gerçek anı (UTC) saklamak ve bunu her görüntüleyenin yerel zamanına çevirmektir.

Bahar DST boşluğunda, ABD saatleri Birleşik Krallık'tan daha erken değişir:

• ABD DST değişmeden önce: Londra'da 10:00 (GMT) New York'ta 05:00 (EST) olarak görünür.
• ABD değiştikten sonra ama İngiltere değişmeden önce: Londra'da 10:00 (halen GMT) New York'ta 06:00 (EDT) olarak görünür.
• İngiltere değiştikten sonra: Londra'da 10:00 (BST) yeniden New York'ta 05:00 (EDT) olarak görünür.

Organizatör için hiçbir şey "hareket etmedi." Toplantı Londra saatinde 10:00'da kaldı. Değişen tek şey birkaç hafta boyunca New York'un offset'i oldu.

Hatırlatmalar her kişinin gördüğü şeye göre olmalıdır, geçmişte "gördükleri"ne göre değil. New York'taki katılımcının 15 dakikalık hatırlatması varsa, ABD değişimi öncesinde 05:45'te, boşluk haftalarında 06:45'te tetiklenmelidir; kimse etkinliği düzenlemese bile.

Bir düzenleme ekleyin: iki erken sabahın ardından Londra organizatörü ertesi haftadan itibaren standupu 10:30 Londra saatine alırsa, iyi bir sistem niyeti korur: değişikliği organizatörün zonunda uygular, gelecekteki örnekler için yeni UTC anları üretir ve geçmiş örnekleri olduğu gibi bırakır.

İyi metin destek biletlerini azaltır: "Her Salı 10:00 (Londra saati) tekrarlanır. Davetliler bunu kendi yerel zamanlarında görür. Saatler yaz saati uygulaması başladığında veya bittiğinde 1 saat değişebilir."

Sonraki adımlar: daha net UX metinleri ve daha güvenli bir inşa planı

Çoğu "zaman dilimi hatası" aslında beklenti hatasıdır. Veri modeliniz doğru olabilir ama arayüz metniniz belirsizse insanlar uygulamanın onları okumasını bekler. Zaman dilimlerini bir arayüz vaadi olarak ele alın, sadece arka uç detayı olarak değil.

Zamanın bulunduğu her yerde zaman dilimini adlandıran metinle başlayın, özellikle bildirimlar ve e-postalarda. Sadece "10:00 AM"e güvenmeyin. Zon'u yanında gösterin ve formatı tutarlı tutun.

Kafa karışıklığını azaltan metin örnekleri:

• "Sal, 12 Mar, 10:00 AM (America/New_York)"
• "Sizin için bu 15:00 (Europe/London)"
• "Bu etkinlik şu zaman diliminde kaydedildi: New York saati"
• "Seyahat ederseniz, bu toplantı New York saatinde kalır"
• "Yaz saati uygulaması başladığında veya bittiğinde saatler 1 saat değişebilir"

DST günleri için dostça hata mesajları da gerekir. Kullanıcı var olmayan bir zaman seçerse (örneğin bahar-ileri gecesinde 02:30), teknik dil kullanmayın ve seçenek sunun: "02:30 10 Mar'da saat değişikliği nedeniyle mevcut değil. 01:30 veya 03:30 seçin." Bir saat iki kez olduğunda açıkça sorun: "İlk 01:30 mu yoksa ikinci 01:30 mu demek istediniz?"

Daha güvenli inşa etmek için tam akışı (oluştur, davet et, başka bir zonda görüntüle, DST sonrası düzenle) prototipleyin:

• Kuralları bir paragrafta yazın (ne sabit kalır, ne dönüştürülür).
• Veri modelini taslaklayın (UTC artı orijinal IANA zaman dilimi sakla).
• E-posta ve bildirim metnini UI ile birlikte taslaklayın.
• Üç senaryoyu test edin: seyahat, bahar-ileri, sonbahar-geri.
• Kararları kilitleyin, sonra uygulayın.

Hızla bir planlama özelliği inşa ediyorsanız, Koder.ai gibi sohbetten uygulamaya platformlar kurallar, şema ve UI üzerinde hızla yineleme yapmanıza yardımcı olabilir. Hız iyidir, ama aynı disiplin geçerlidir: anları UTC olarak saklayın, etkinliğin niyeti için IANA zonunu tutun ve kullanıcıların hangi zaman dilimine baktığını her zaman gösterin.