AI aylık planında 31 Ocak neden martta 28’ine kayıyor?

Şubatın kısalması neden martı da etkiliyor?

Her ayın 31’inde kişisel arşivinizi gözden geçirmek istiyorsunuz. Yapay zekânın planı 31 Ocak, 28 Şubat, 28 Mart diye ilerliyor. Şubatta 31 bulunmadığı için son güne geçilmesi makul; martın da 28’e taşınması ise farklı bir karar. Model her yeni tarihi bir önceki sonuçtan üretmiş olabilir. İlk isteğinizdeki gün bilgisini korumak için tekrarın başlangıç çıpasını, gerçekleşen tarihten ayrı tutun.

Bu yazının sözleşmesi açık: her hedef ayda istenen gün 31; o gün yoksa yalnız o ayın son günü kullanılır. İş günü veya resmî tatil düzenlemesi yapılmaz. Saat ve saat dilimi hesap dışıdır. Bu tercih bütün takvim ürünlerinin varsayılan davranışı olarak sunulmaz. Aylık tekrarın ne anlama geldiğini kullanıcı belirler; araç önerisi bu anlamı uygulamalıdır.

Tarih üretmek için üç bilgi gerekiyor

Başlangıç çıpası: 2027-01-31. İstenen gün: 31. Hedef ay farkı: 0,1,2,3,4,5. Politika: hedef ayda 31 yoksa o ayın son günü. Her tarih özgün çıpadan üretilir. Sonuç tarihinin günü yeni çıpa yapılmaz. Gerçek takvime kayıt eklenmez.

Ay farkı hedef yıl ve ayı belirler. Gün ise 31 ile o ayın gün sayısından küçük olanıdır. Böylece Şubat 28, Nisan 30 olurken Mart ve Mayıs yeniden 31 olabilir. Çıpa yalnız ilk tarihi hatırlamak için tutulmuyor; kısa ayda geçici olarak uygulanamayan gün tercihini de koruyor. Sonuçtan sonraki sonucu türetmek bu tercihi kaybedebilir.

dateutil belgesi ay ekleme örneğinde 31 Ocak’tan bir ay sonrasını 28 Şubat, iki ay sonrasını 31 Mart olarak gösterir. Hedef ayın son gününü aşan sonuç ay sonuna alınır. Buradaki altı aylık çizelge bu davranıştan yararlanan özgün bir eğitim tasarımıdır. Belgenin örneği, bütün takvim uygulamalarının aynı tekrarı ürettiği veya kullanıcı niyetini kendiliğinden bildiği anlamına gelmez.Kaynak: dateutil — relativedelta

Aynı ilk iki tarih, farklı devam

İki yöntem ocak ve şubatta aynı sonuç verdiği için yalnız ilk tekrarı kontrol etmek hatayı göstermez. İlk fark martta belirir. Zincirleme yöntem artık 28’i koruyor; gün sayısı yeterli olduğunda bile 31’e dönmüyor. Bu tabloda iki farklı algoritmanın çıktıları var. Zincirleme yöntem kendi tanımı içinde tutarlıdır, ancak yazının başındaki kullanıcı tercihini karşılamaz.

Takvimdeki altı kaydın bulunması da yeterli kontrol değildir. Her kaydın hedef ayı bir kez temsil etmesi ve gününün özgün kurala uyması gerekir. Örneğin yanlış mart kaydı ayı atlamaz, geçersiz tarih üretmez ve sıralamayı bozmaz. Sorun yalnızca istenen günün kaybolmasıdır. Kontrolünüz yalnız geçerli tarih veya kayıt sayısı üzerinden kurulursa bu tür anlam değişimi görünmez kalır.

Ayın son günü, otuz birinci günle aynı kural değil

31 Ocak başlangıcında “her ayın son günü” tercihi de aynı ilk çizelgeyi üretir. Bu eşitlik iki kuralın her zaman aynı olduğu anlamına gelmez. Başlangıcı 30 Ocak yapın: gün çıpası martta 30’u, ay sonu tercihi martta 31’i seçer. İki farklı kuralı ayırmak için sonuçlarının farklılaştığı bir başlangıç kullanmak gerekir. Bu küçük karşı örnek, takvim üretimine yönelik yararlı bir kabul testidir.

Ayrıca “bir ay sonra” ile “otuz gün sonra” farklıdır. Aylar sabit uzunlukta olmadığı için her defasında otuz gün eklemek de başka bir dizi üretir. Planınız bir ayın belirli gününü hedefliyorsa sabit gün sayısı ekleme yolunu sessizce seçmeyin. Bir son tarih iş gününe taşınacaksa önce aylık çıpa tarihini üretin, ardından ayrı iş günü politikasını uygulayın; taşınmış son tarihi yeniden çıpa yapıp yapmayacağınızı ayrıca belirtin.

AI’dan iki algoritmayı karşılaştırmasını isteyin

2027-01-31 başlangıcından ocak–haziran için aylık arşiv kontrolü planla. Gün tercihi 31; hedef ay kısa ise yalnız o ayın son gününü kullan. Her ayı başlangıç çıpası ve ay farkıyla hesapla. Karşılaştırma olarak önceki sonuca bir ay ekleyen zinciri de göster. Çıktı: hedef ay, gün sayısı, iki tarih ve fark gerekçesi. Hafta sonu, tatil veya saat ekleme. Altı hedef ay korunmalı; mart 31 olmalı. Takvime gerçek kayıt yazma.

Çıpalı sonuç: 31 Ocak, 28 Şubat, 31 Mart, 30 Nisan, 31 Mayıs, 30 Haziran. Zincir şubattan sonra 28’de kalır. İlk ayrışma martta. Karar: kullanıcı sözleşmesi için çıpalı sonuç kullanılacak; kısa ayın geçici düzeltmesi istenen günü değiştirmeyecek.

Yanıtı incelerken modelden neden martta 31’e geri dönüldüğünü açıklamasını isteyin. “Takvim otomatik düzeltti” açıklaması yerine özgün gün tercihi ve ayın uzunluğu gösterilmeli. Bu iki alan görünürse farklı bir uygulamaya aktarırken de sonucu bağımsız hesaplayabilirsiniz. Hesabın açıklaması, belirli bir uygulamanın ekranına veya sürümüne bağlı değildir.

Çıpayı değiştirerek kuralı sınayın

Başlangıç 2027-01-30, gün tercihi 30 ve kısa ayda son güne geçme politikası olsun. Şubat, mart ve nisanı bulun. Ardından başlangıcı koruyup yalnız tercihi “her ayın son günü” yapın. Hangi ayların farklılaşacağını önceden tahmin edin; sonra ay uzunluklarıyla karşılaştırın. Şubatta çıkan 28’i yeni kalıcı gün saymayın.

Gün 30 çıpası: 28 Şubat, 30 Mart, 30 Nisan. Ay sonu kuralı: 28 Şubat, 31 Mart, 30 Nisan. Fark martta bir gündür. İki plan da geçerli tarihler üretir; yalnız tercihleri farklıdır.

Tekrar çizelgesini paylaşırken çıpa, ay adımı ve kısa ay politikasını yanında tutun. Böylece bir tarihin elle taşınması bütün sonraki ayları değiştirmek zorunda kalmaz. Çalışmanın çıktısı altı satırın yanında yeniden üretilebilir bir kuraldır; sonraki yıl aynı niyetle yeni çizelge üretmek için gereken bilgi burada korunur.