ICS MakerYanlış saat dilimi

Etkinlik yanlış saatte düştüğünde

Neredeyse her "davet bir saat kaymış" sorunu şu üç şeyden biridir: bölgesi olmayan bir saat, okuyan takvimin tanımadığı bir bölge veya tüm gün süren bir etkinliğin saatli bir etkinlik gibi ele alınması.

Başlık, konum, tarih ve saat, saat dilimi, tekrar, davetliler, uyarılar ve notlar — ardından .ics dosyasını indirin veya doğrudan takviminizde açın. Aynı anda birden çok etkinlik oluşturmak için bir program yapıştırabilir ya da belge veya fotoğraf ekleyebilirsiniz.

Takvim etkinliğim neden bir saat veya bir gün kayıyor?

Bir .ics dosyası saati üç şekilde ifade edebilir ve neredeyse her zaman sorunun nedeni yanlış olanıdır. Değişken (floating) bir saat (DTSTART:20260815T090000, bölgesiz), nerede açılırsa açılsın saat dokuzdur. UTC saati (sonunda bir Z ile) tek bir mutlak andır. Adlandırılmış bir bölge (DTSTART;TZID=Europe/London:...) ise, yaz saati uygulaması boyunca aynı yerel saatte kalan bir andır. Bir saat kayan bir içe aktarma genellikle okuyan takvimin tanımadığı ve bu yüzden UTC'ye geri döndüğü 'GMT Standard Time' gibi Windows tarzı bir bölge adından kaynaklanır; bir gün kayan tüm gün süren bir etkinlik ise genellikle VALUE=DATE gerekirken gece yarısı zaman damgası kullanılmasından ya da DTEND kapsayıcı olmadığından bitiş tarihinin bir sonraki gün yerine son güne yazılmasından kaynaklanır. ICS Maker varsayılan olarak değişken bir saat yazar ve bir bölge seçildiğinde IANA bölgesini adlandıran bir TZID yazar — ancak her yaygın takvimin bölge adının kendisinden çözümlediği gömülü bir VTIMEZONE bloğu olmadan.

Bir dosyanın zamanı ifade edebileceği üç yol

Değişken (floating) — bölge yok
DTSTART:20260815T090000. Nerede açılırsa açılsın sabah dokuz. Yerel bir randevu, bir hatırlatıcı veya okuyucunun kendi saatiyle tanımlanan herhangi bir şey için doğrudur; farklı ülkelerdeki iki kişinin buluşması gerektiği anda yanlış olur.
UTC — mutlak bir an
DTSTART:20260815T090000Z, sonundaki Z ile. Zamanda tek bir an, onu her ne açıyorsa yerel saate çevrilir. Belirsizlik taşımaz, ancak toplantının "Londra'da saat on" olduğu bilgisini kaybeder, bu yüzden bir yaz saati değişikliği onu kaydırır.
Adlandırılmış bölge — yaz saati uygulamasında hayatta kalan bir an
DTSTART;TZID=Europe/London:20260815T090000. Tekrarlanan bir toplantının istediği tam olarak budur: ofset altta kaysa bile seri yerel saatle on'da kalır. RFC 5545, o bölgenin ofsetlerini tanımlayan eşleşen bir VTIMEZONE bloğunun yanında bulunmasını ister.

Bu oluşturucu varsayılan olarak ilkini, listeden bir bölge seçtiğinizde ise üçüncüsünü yazar. Bu varsayılan bilinçli bir seçimdir: saat dokuzdaki bir diş randevusu dokuzda olmalıdır ve dosyayı oluşturan makinenin bölgesini eklemek, etkinliğin onu okuyan kişi için bir saat kaymasına yol açan şeydir.

TZID bölgesini gömülü bir VTIMEZONE bloğu olmadan yazar, bu da dosyayı alışılmadık bir yere göndermeden önce bilinmesi gereken bir noktadır. Apple Calendar, Google Calendar, Outlook ve Thunderbird'ün tümü IANA saat dilimi veritabanını taşır ve Europe/London'yi yalnızca isimden çözümler, bu yüzden söz konusu blok, okuyucunun zaten bildiği şeyi yeniden ifade eden yüzlerce satır olurdu. Yalnızca dosyanın kendisinde tanımlanan bölgeleri çözümleyen katı bir ayrıştırıcı, bu değiş tokuşun karşılığını vermediği durumdur — birine böyle bir dosya besliyorsanız VTIMEZONE bloğunu elle yapıştırın.

Yanlış gelen bir dosyayı okumak

Bir metin düzenleyicide açın ve DTSTART satırına bakın, çünkü cevap her zaman oradadır. Beklemediğiniz bir ofsetle biten bir Z, gönderenin paylaşmadığınız bir bölgeden UTC'ye dönüştürdüğü anlamına gelir. Europe/London yerine GMT Standard Time gibi bir şey adlandıran bir TZID, Microsoft Exchange'in yazımıdır ve yalnızca IANA isimlerini bilen takvimler UTC'ye geri dönebilir — ki bu klasik bir saat kaymış içe aktarmadır. Ne bir IANA adı ne de aynı dosyada bir VTIMEZONE bloğu tarafından tanımlanan bir bölgeyi adlandıran bir TZID, her okuyucunun farklı şekilde tahmin ettiği ve yeterince sık UTC'yi tahmin ettiği durumdur, bu yüzden kontrol edilecek ikinci şeydir.

Bir gün kayan tüm gün süren etkinlik

Tüm gün süren bir etkinlik bir saat değil, bir tarihtir: DTSTART;VALUE=DATE:20260815. Bunun yerine gece yarısı bir zaman damgası olarak yazıldığında, gerçek bir an haline gelir ve batıya doğru herhangi bir dönüşüm onu önceki güne sürükler. Bitiş tarihi tuzağın diğer yarısıdır — kapsayıcı değildir, bu yüzden 15'indeki tek bir gün 16'sında biter ve 15'inde biten bir dosya bazı takvimlerde hiçbir şey göstermez.

Sorular

Takvim etkinliğim neden bir saat kaymış?
Neredeyse her zaman bir yaz saati uyuşmazlığıdır: dosya sabit bir UTC ofseti veya okuyan takvimin tanımadığı Windows tarzı bir bölge adı belirtir ve okuyucu UTC'ye geri döner. DTSTART satırını kontrol edin — eğer Z ile bitiyorsa saat mutlak UTC'dir ve eğer bir TZID taşıyorsa o bölgenin Europe/Paris gibi bir IANA adı olarak yazılması ya da aynı dosyada bir VTIMEZONE bloğu tarafından tanımlanması gerekir. Yaygın takvimler IANA adını kendi saat dilimi veritabanı kopyalarından çözümler ve böyle bir bloğa ihtiyaç duymaz.
Bir saat dilimi ayarlamalı mıyım yoksa boş mu bırakmalıyım?
Etkinlik yerel saatle tanımlandığında boş bırakın — bir randevu, bir hatırlatıcı, nerede olursanız olun dokuzda başlayan bir ders. Etkinlik, diğer bölgelerdeki konukların dönüştürmesi gereken tek bir anda gerçekleştiğinde, örneğin bir görüşme, bir web semineri veya bir yayın olduğunda bir tane ayarlayın.
Değişken (floating) saat nedir?
Bölgesi ve sonunda Z'si olmadan yazılan, RFC 5545'in okunduğu her yerde yerel saat olarak yorumlanmasını söylediği bir tarih-saattir. İnsanların beklediğinden daha sık doğru seçimdir ve farklı bölgelerdeki iki okuyucunun bir an üzerinde anlaşması gerektiğinde yanlış olanıdır.
Tüm gün süren etkinliğim neden yanlış günde görünüyor?
Çünkü bir tarih değeri olarak değil, gece yarısında bir zaman damgası olarak yazılmıştır. Gerçek bir tüm gün etkinliği, hiç saat içermeyen VALUE=DATE kullanır, bu yüzden dönüştürülecek bir şey yoktur. Ayrıca bitiş tarihinin kapsayıcı olmadığını unutmayın: 15'indeki tek günlük bir etkinliğin DTEND'i 16'sındadır.