Bir yapay zekâ aracının takvim dosyası üretmesi, yinelenen etkinliklerin her takvim uygulamasında aynı tarihlerde ve aynı yerel saatte açılacağını tek başına göstermez. Dosya içindeki başlangıç, tekrar kuralı, saat dilimi ve istisna alanları birbirini tutsa bile hedef uygulama bunları farklı yorumlayabilir. Bu rehber, toplantı notu çıkarmaktan veya takvim uygulamalarını genel olarak sıralamaktan ziyade, AI ile oluşturulan tekrar eden etkinlik dosyasını önceden tanımlanmış beklenen örneklerle sınamak isteyen ekipler içindir.

Önce hangi çıktıyı test ettiğinizi belirleyin. RFC 5545, iCalendar biçimini belirli bir takvim hizmetinden bağımsız biçimde tanımlar; ancak bu, her uygulamanın her alanı aynı arayüzle sunduğu veya üretilen dosyanın kusursuz olduğu anlamına gelmez. IANA saat dilimi verileri de yerel saat kurallarındaki siyasi değişikliklere göre güncellenir. Dolayısıyla doğrulama, yalnız dosyanın açılıp açılmadığına değil; kuralın hangi kaynak ve uygulama sürümünde nasıl davrandığına dayanmalıdır.

Test edilecek takvim görevini sınırlandırın

“Takvim oluştur” ifadesi bir doğrulama ölçütü değildir. Hangi etkinliklerin, ne sıklıkta ve hangi bitiş koşuluyla tekrarlanacağını açıkça yazın. Örneğin haftanın belirli iki günü, belirli bir yerel başlangıç saati ve sekiz oluşumdan sonra sona eren bir seri test edilebilir. Gerçek ekip adları, davetli adresleri, müşteri toplantıları veya rezervasyon verileri gerekmez; test için kurgusal başlıklar ve tarih aralıkları kullanın.

AI aracına verilecek talimatı sabitleyin: kullanıcı girdisi, istenen dosya biçimi, saat dilimi, varsayılan kabul edilen değerler ve modelin bilmediği durumda ne yapacağı aynı test kaydında bulunsun. “Eksik bilgiyi en makul seçenekle tamamla” yerine “belirtilmemiş alanı sor” kuralını koyun. Aynı girdiyi farklı oturumlarda karşılaştıracaksanız araç adı, arayüz veya API sürümü, varsa model seçimi ve çalıştırma tarihini not edin. Bu kayıt, değişen sonucu hangi koşulun etkilediğini anlamanızı sağlar; ürünler arasında genel bir başarı sıralaması üretmez.

Beklenen tekrar listesini dosyadan önce çıkarın

İçe aktarmadan önce küçük bir “beklenen oluşumlar” listesi hazırlayın. Her satırda seri kimliği, yerel tarih ve saat, süre, saat dilimi kimliği, tekrar aralığı, haftanın günü, beklenen toplam oluşum ve bitiş koşulu yer alsın. İstisna tarihi varsa, o tarihte ne beklediğinizi ayrıca belirtin: etkinlik tamamen çıkarılacak mı, başka güne mi taşınacak, yoksa saat mi değişecek? Bir insan bu listeyi dosyayı görmeden hazırlamalı; aksi hâlde test ölçütü AI çıktısına uydurulabilir.

Ardından seri tanımını oluşum listesiyle karşılaştırın. Haftalık kural doğru günleri seçmiş mi? Başlangıç olayı tekrar kümesinde bir kez mi görünüyor? Sayı sınırı hedeflenen toplamla uyumlu mu? Bitiş tarihi geçildiğinde fazladan kayıt üretiliyor mu? COUNT sayacı başlangıç olayını da içerir; EXDATE ile çıkarılan bir tarih son oluşum kümesinde görünmemelidir. Bu nedenle beklenen toplamı istisna uygulandıktan sonra hesaplayın. “Her ayın son iş günü” gibi talimatlarda uygulama desteğini ayrıca doğrulayın.

Doğrulamada yalnız ilk ve son olaya bakmak yeterli değildir. Serinin ortasından bir tarih, ay sonuna yakın bir tarih ve saat dilimi kurallarının değiştiği döneme denk gelen bir oluşum seçin. Çıktıdaki tüm tarihleri önceden hesaplanmış listeyle karşılaştırın. Tekrarlı örnekler eksik, fazla veya yanlış sıradaysa “dosya içe aktarıldı” sonucunu başarı olarak işaretlemeyin. Hata, hangi oluşumda ve hangi kuralın etkisiyle ortaya çıktıysa o düzeyde kaydedilsin.

Yerel saat ile sabit UTC saatini ayırın

Bir davetin “her salı 09.00” talimatı, her hafta aynı yerel saat anlamına gelebilir. Buna karşılık UTC’de sabit bir saate bağlanan olay, yerel saat kuralları değiştiğinde takvimde farklı saatte görünebilir. Bu iki ihtiyacı birbirine karıştırmayın. Test tanımına saat dilimi kimliğini ve önceliğin her seferinde aynı yerel saati mi yoksa UTC’ye göre günün aynı saatini mi korumak olduğunu yazın. Yalnız “+03.00” gibi sabit bir fark, gelecekteki bütün yerel saat kurallarının kalıcı tarifi değildir.

Yaz saati uygulayan temsilî bir IANA bölgesi seçerek değişim öncesi ve sonrası haftaları test edebilirsiniz; bu, o bölgede gerçek toplantı yapıldığı iddiası değildir. Saatin duvar saatinde aynı kalması bekleniyorsa iki örneğin yerel saatini karşılaştırın. UTC’ye göre aynı saat korunacaksa her oluşumun tarihini ve yerel saat karşılığını ayrı kaydedin. Tarih değişimi, tekrarlanan etkinliğin bir gün önceye veya sonraya kayması, çift oluşum ya da eksik oluşum gibi sonuçları birbirinden ayırın.

RFC 5545, saat dilimli tarih-saat değerleri, tekrarlama kuralları ve istisna tarihleri için yapısal alanlar tanımlar. Bazı dosyalarda yerel saat dilimi bilgisini açıklayan VTIMEZONE bileşeni bulunabilir; başka bir uygulama tanınmayan veya güncel olmayan bir tanımla karşılaşabilir. IANA veri tabanının güncellenebilir olması nedeniyle, aynı çıktı aylar sonra farklı işletim sistemi veya takvim sürümünde yeniden sınanabilir. Bu yüzden dosyanın kullandığı zaman dilimi tanımını ve test ortamındaki takvim yazılımını saklayın; tek bir görüntüye bakıp tüm platformların aynı davranacağını iddia etmeyin.

İstisna tarihlerini ayrı hata sınıfı yapın

Bir seri için tatil, bakım günü veya tek seferlik erteleme belirtildiyse, bunu tekrar kuralının geneliyle karıştırmayın. Test tablosunda normal oluşum, çıkarılacak oluşum ve yeri değiştirilecek oluşum ayrı satırlarda dursun. Beklenen listeye istisnanın etkisini önceden yazın. Dosyayı açınca istisna tarihinin görünmemesi, doğru uygulandığı anlamına gelmeyebilir: seri başka tarihe kaymış, tüm seri silinmiş veya çıkarılması gereken tarih hâlâ duruyor olabilir.

iCalendar’da EXDATE belirli oluşumları tekrar kümesinden çıkarabilir; RECURRENCE-ID ise yinelenen seride belirli bir oluşumu tanımlamak için kullanılır. Bunların dosyada bulunması, hedef uygulamanın değişikliği beklediğiniz gibi sunacağının kanıtı değildir. Ayrı bir test takviminde çıkarma ve tekil erteleme senaryosunu deneyin. Seri sahibi görünümünde değişiklik yapılsa bile eski bir dosyanın tekrar içe aktarılmasıyla kopya oluşup oluşmadığını ayrıca kontrol edin; yinelenen dosya yüklemesini asıl doğruluk testiyle karıştırmayın.

İçe aktarma biçimini araç iddiasından ayırın

Bir AI aracı hem ICS hem CSV dosyası üretebiliyorsa, iki biçimi aynı özelliklere sahipmiş gibi değerlendirmeyin. CSV satır ve alan aktarımında kullanışlı olabilir; fakat yinelenme kuralı, saat dilimi tanımı ve istisna davranışı hedef hizmetin CSV içe aktarma desteğine bağlıdır. Google Calendar yardım belgesi, CSV’den içe aktarılan tekrar etkinliklerin seri olarak görünmeyip tekil etkinlikler hâlinde oluşabileceğini belirtir. Bu, Google’ın belirttiği CSV davranışıdır; her ürüne veya ICS dosyasına genellenmemelidir.

Dosya biçimiyle test uygulamasını birlikte kaydedin. İçe aktarma sonrası bir etkinliğe tıklayıp yalnız başlığı görmek yerine seri ayarlarını, yerel saati, bitiş koşulunu ve istisna tarihlerini arayüzde inceleyin. İçe aktarım eşitleme değildir: Google’ın belgesi, iki hesap arasında içe alınan etkinliklerin senkronize kalmadığını da söyler. Testin amacı kalıcı çift yönlü bağlantı değil, o anki aktarım sonucunu doğrulamaktır. Otomatik davet, konferans bağlantısı veya müsaitlik bilgisi gibi alanların aktarılacağını varsaymayın; ürün belgesinde desteklenmeyen alanı kapsam dışı yazın.

Küçük bir regresyon matrisi kullanın

Her çalıştırmada şu senaryoları işaretleyin: tek etkinlik; haftalık iki gün; ayda bir belirli gün; son oluşum sayısıyla biten seri; bitiş tarihiyle sınırlandırılan seri; çıkarılmış tek tarih; taşınmış tek tarih; saat dilimi kuralı değişiminden önce ve sonra oluşan tarih. Kontrollü örnekleri ayrı dosyalarda sınayın. Böylece bir alanın hatası diğer senaryoların sonucunu maskelemez.

Beklenen ile gözlenen sonucu sütunlarda karşılaştırın: oluşum sayısı, tarih, yerel saat, UTC karşılığı, hariç tutulanlar, kaynak alanı ve inceleyen kişinin kararı. Hata varsa “yanlış” yazıp geçmeyin. Örneğin “istisna listesi içe aktarma sonrasında uygulanmadı”, “saat dilimi kaybolduğu için yerel saat bir saat değişti” veya “önceden hesaplanan son kümede eksik veya fazla oluşum bulundu” gibi tekrar edilebilir tanım kullanın. Bu tanımlar model sağlayıcısına yöneltilecek hata bildirimi veya yeni istem denemesi için daha kullanışlıdır.

Canlı takvime geçmeden önce güvenli kontrol

İlk denemeyi ayrı ve erişimi sınırlı bir test takviminde gerçekleştirin. Gerçek katılımcı eklemeyin; davet gönderimini ve otomatik konferans oluşturmayı kapalı tutun. Örnek etkinlikleri “TEST” olarak adlandırın ve çalışmanın sonunda temizleme sorumlusu ile kaldırılacak kayıtları listeleyin. Dosyayı açabilen kişinin bunu üretim takvimine doğrudan yüklemesine izin vermek, doğrulama adımını atlayabilir. Üretime aktarım gerekiyorsa dosyayı ve oluşum listesini yetkili bir kişi ikinci kez karşılaştırsın.

İnsan kontrolünün sınırlarını da kaydedin. Görüntüde veya içe aktarma ekranında belirsiz kalan alanı tahminle doldurmayın; tarih ya da saat dilimi bilgisini üretim aracından veya talep sahibinden açıkça isteyin. AI taslağı iş yükünü azaltabilir, ancak canlı davetleri, kaynak takvimle senkronizasyonu veya alıcıların katılım durumunu otomatik olarak güvence altına almaz. Kurumun takvim politikası, erişim yetkisi ve kişisel veri kuralları bu test rehberinden bağımsız şekilde uygulanır.

Toplantı notlarından tarih ve eylemi kaynağa bağlama için eylem kaydı rehberini; CSV satır ve alan kontrolü için teslim bütünlüğü yazısını inceleyin. Hizmet kapsamı burada açıklanmıştır.

Sık Sorulan Sorular

Bir ICS dosyası açılıyorsa tekrarları doğru demek midir?

Hayır. Dosyanın açılması yalnız biçimin uygulama tarafından okunabildiğini gösterir. Beklenen oluşum sayısını, günleri, başlangıç saatini, saat dilimini, bitiş koşulunu ve istisna tarihlerini ayrı ayrı karşılaştırın. Tek bir oluşumun görünmesi serinin doğru olduğu anlamına gelmez.

AI’ın yazdığı tekrar kuralını nasıl kontrol ederim?

Dosyayı açmadan önce beklenen tarih listesini bağımsız olarak hazırlayın. Haftanın günlerini, başlangıç tarihini, toplam oluşum sayısını ve sona erme koşulunu yazın. Ardından oluşumları uygulamada listeleyip her satırı beklentiyle karşılaştırın. Farkı “yakın” kabul etmeyin; açıklamadan üretim takvimine taşımayın.

Saat dilimi yerine UTC farkı yazmak yeterli mi?

Her zaman değil. Sabit UTC farkı tek bir anı tarif edebilir, fakat gelecekteki yerel saat kuralları siyasi kararla değişebilir. Tekrar eden etkinliğin her hafta aynı yerel saatte kalması gerekiyorsa isimli saat dilimi tanımı ve hedef uygulama davranışı önem taşır. İhtiyaca göre yerel ve UTC saatini birlikte sınayın.

Yaz saati değişiminde hangi sonucu beklemeliyim?

Önce gereksiniminizi belirleyin: yerel duvar saati mi korunacak, yoksa UTC’ye göre günün aynı saati mi? Bunlar saat farkı değiştiğinde farklı sonuç verebilir. Değişim öncesi ve sonrası oluşumları seçip tarih, yerel saat ve UTC değerlerini ayrı kaydedin. Test bölgesi ve yazılım sonucu etkiler.

İstisna tarihinin dosyada bulunması yeterli mi?

Hayır. Hariç tutulması veya başka güne taşınması gereken etkinliğin içe aktarımdan sonra gerçekten doğru davranıp davranmadığını kontrol edin. Kaynak dosyada yer alan bir alan, hedef uygulamada aynı biçimde uygulanmayabilir. Test takviminde seri ve tekil oluşumu kontrol edin.

CSV ile ICS aynı tekrar davranışını verir mi?

Varsaymayın. Google Calendar yardım sayfası, CSV’den içe alınan tekrar etkinliklerin tekil olaylara dönüşebileceğini belirtir. Bu, Google’ın CSV’ye özgü notudur. ICS kuralını, saat dilimini ve istisnaları ayrıca sınayın.

Google Calendar’a aktarmak kaynakla senkronizasyon sağlar mı?

Hayır. Google’ın içe aktarma yardım belgesi, aktarılan etkinliklerin iki hesap arasında eşitlenmeye devam etmediğini belirtir. Aktarım kaynakla eşitleme değildir; sonraki değişiklikler hedefe yansımayabilir. Sürekli güncellik için desteklenen ayrı bir eşitleme yöntemi gerekir.

AI çıktısını doğrudan gerçek davetlilere gönderebilir miyim?

Bu rehber böyle bir geçiş önermiyor. Önce davetsiz, ayrı test takviminde tarih ve tekrar kurallarını doğrulayın. Üretim öncesi yetkili kişi tarihleri, saat dilimini, istisnaları ve alıcıları doğrulasın. Belirsiz alanı model tahminiyle doldurmayın; sorun.