Tarih/Saat: Luxon, Alman Formatları, Saat Dilimi Tuzakları

n8n, tarih ve saati dahili olarak JavaScript'in yerel Date nesnesi üzerinden değil, JavaScript kütüphanesi Luxon üzerinden işler. Bunu genellikle ancak bir workflow bir saat kaymış bir tarih verdiğinde, bir ay adı Almanca yerine İngilizce göründüğünde ya da bir belge ay sonunda aniden yanlış günde ortaya çıktığında fark edersin. Luxon'un saat dilimini, dili ve formatı nasıl net biçimde ayırdığını anladığın anda, tam olarak bu hataları bilinçli şekilde önleyebilirsin ve sonunda faturada, CRM'de veya tabloda gerçekten hangi tarihin yer aldığı üzerinde kontrolü elinde tutarsın.

Bu makale bilinçli olarak ifadelerde ve Date & Time Node içinde tarih ve saat biçimlendirmesine odaklanır, Schedule Trigger'ın veya Cron ifadelerinin saat dilimi mantığına değil. Bu, kendi tuzakları olan ve ayrı bir bakışı hak eden başlı başına bir konudur.

n8n neden Luxon kullanıyor

Saf JavaScript, en temel düzeyin ötesine geçen saat dilimleri veya dil formatları için yerleşik bir kavram tanımaz. Luxon tam olarak bu boşluğu doldurur: n8n'in dahili olarak ürettiği her tarih, örneğin $now veya $today üzerinden, kendi saat dilimine, kendi diline (locale) ve kendi hesaplama, karşılaştırma ve biçimlendirme yöntemlerine sahip bir Luxon DateTime nesnesidir. n8n'de tarih ve saat konusundaki resmi dokümantasyona göre, tarih değerleri node'lar arasında string olarak aktarılır ve hesaplamalar veya biçimlendirme için önce yeniden Luxon fonksiyonlarıyla ayrıştırılmalıdır. JavaScript'in yerel Date() nesnesi n8n'de ayarlanan saat dilimine uymaz, bu yüzden dokümantasyon tarih ve saatle ilgili her şey için Luxon'da kalmayı açıkça önerir.

İfadelerde bir tarihi biçimlendirmek

Asıl biçimlendirme için ifadelerde, Almanca gereksinimlere farklı derecelerde uygun olan birkaç yol açıktır:

• .toFormat(fmt): sabit token'lar üzerinden kendi formatını kendin oluşturduğun yerel Luxon yöntemi, örneğin dd.MM.yyyy. Her yerde çalışır, Code Node'da da dahil.
• .toLocaleString(opts): yerelleştirilmiş, yani dile bağlı bir format döndürür. Locale ayarlanmamışsa sonuç n8n instance'ının varsayılan diline göre şekillenir, bu da pratikte çoğunlukla İngilizce anlamına gelir.
• format(): tarih biçimlendirmesi için n8n'e özgü bir ifade dili uzantısı; DateTime ifade referansına göre Code Node'da kullanılamaz. Orada bunun yerine yerel .toFormat() işlevine başvurursun.
• Date & Time Node'daki hazır formatlar: Node, MM/DD/YYYY veya YYYY-MM-DD gibi sabit ön ayarların yanı sıra özel bir format için bir seçenek de sunar. Date & Time Node dokümantasyonuna göre n8n bunun için Luxon'un kendisinin de bildiği tüm formatları destekler, ancak token'lar büyük/küçük harfe duyarlıdır.

Salt sayısal bir Alman tarihi için genellikle sabit bir token deseniyle .toFormat() yeterlidir; buna karşılık yazılı ay veya haftanın günü adlarının Almanca görünmesi gerektiğinde .toLocaleString() ve .setLocale() önem kazanır.

Doğru Alman formatları üretmek

Klasik Alman yazımı TT.MM.JJJJ için locale bağımlılığı olmayan sabit bir ifade yeterlidir:

• {{$now.toFormat('dd.MM.yyyy')}} örneğin 20.07.2026 sonucunu verir.
• {{$now.toFormat('dd.MM.yyyy HH:mm')}} saati 24 saat formatında ekler.

Örneğin bir fatura veya toplu mektup için yazılı adlar devreye girdiğinde, ek olarak Alman locale'ine ihtiyacın olur, aksi halde ay adı İngilizce olarak verilir:

• {{$now.setLocale('de-DE').toLocaleString({month: 'long', day: 'numeric', year: 'numeric'})}} 20. Juli 2026 gibi bir sonuç verir.
• {{$now.setLocale('de-DE').monthLong}} doğrudan yazılı ay adını döndürür, örneğin Juli.

Burada önemli olan: .setLocale() yalnızca çıktının dilini değiştirir, saat dilimini değil. İki ayarı da ayrı ayrı yapmalısın, aksi halde ay için Almanca bir kelime elde edersin ama bazı durumlarda yine de yanlış saati.

Biçimlendirmede saat dilimi tuzakları

Çoğu hata formatın kendisinden değil, biçimlendirmenin yapıldığı saat diliminden kaynaklanır. Pratikte sürekli karşılaşılan birkaç tuzak:

• Europe/Berlin yerine instance varsayılan saat dilimi: açık bir yapılandırma olmadan, kendi barındırılan bir n8n instance'ı dokümantasyona göre varsayılan olarak America/New York kullanır, n8n Cloud'da ise sistem GMT'ye geri döner. $now ve $today, workflow'a özgü bir ayar veya bir GENERIC_TIMEZONE ortam değişkeni başka bir şey belirtmediği sürece bu instance saat dilimine göre şekillenir. Bunu gözden kaçıran kişi, Alman saatinden birkaç saat sapan zaman damgaları elde eder.
• Önceden .setZone() yapılmadan biçimlendirme: .toFormat() ve .toLocaleString() her zaman DateTime nesnesinin o an sahip olduğu saat dilimindeki saati verir, otomatik olarak Europe/Berlin'i değil. Bir tarih UTC olarak veya yabancı bir saat diliminde bir API'den geliyorsa, önce onu .setZone('Europe/Berlin') ile dönüştürmeli ve ancak sonra biçimlendirmelisin, aksi halde Alman saatiyle 23:30'da oluşturulmuş bir belge, raporda aniden bir sonraki günde ortaya çıkar.
• Yaz saati ve kış saati: Europe/Berlin, UTC'ye göre saat farkını yılda iki kez değiştirir. Böyle bir geçişin üzerinden .plus({days: n}) ile hesaplama yapıp ardından saati biçimlendirirsen, takvim günü doğru olsa bile saat kısmı bir saat kayabilir. Sadece saatsiz tarih karşılaştırmaları için bu genellikle kritik değildir, ancak zamana duyarlı süreçler için bunu hesaba katmalısın.
• Ofset ile .toISO() aktarmakLuxon'un ISO string'i varsayılan olarak saat dilimi ofsetini içerir, örneğin +02:00. Bunun yerine saf UTC veya ofsetsiz bir string bekleyen sistemler bu değeri yanlış yorumlar. Sonucu körlemesine aktarmadan önce hedef sistemde gerçekte hangi formatın beklendiğini kontrol et.

Pratik örnek: fatura tarihini doğru vermek

Pratikten tipik bir durum: bir workflow, UTC zaman damgaları veren bir API'den bir belge tarihi alır ve bundan Almanca bir fatura tarihi üretmesi gerekir. Bunun için ifade birleştirilmiş halde şöyle görünür:

• {{ $json.createdAt.toDateTime().setZone('Europe/Berlin').setLocale('de-DE').toFormat('dd.MM.yyyy') }}

Buradaki sıra rastlantı değildir: önce yerel JavaScript zaman damgası bir Luxon DateTime'a dönüştürülür, ardından doğru saat dilimine kaydırılır, sonra dil ayarlanır ve ancak en sonunda biçimlendirilir. Saat dilimi ve biçimlendirme adımlarını yer değiştirirsen, doğru görünen bir Alman tarihi elde edersin ama muhtemelen yanlış takvim günü için.

Sık sorulan sorular

.toFormat() ile .toLocaleString() arasındaki fark nedir?

.toFormat(), dd.MM.yyyy gibi kendi tanımladığın sabit bir token desenini izler ve locale'den bağımsız olarak her zaman aynı düzeni verir. .toLocaleString() ise ayarlanan dile göre şekillenir ve sırayı olduğu kadar yazımı da otomatik olarak uyarlar; bu da özellikle yazılı ay veya haftanın günü adlarında farkı yaratır.

Almanya'da çalışmama rağmen ay adı neden İngilizce görünüyor?

Açık bir .setLocale('de-DE') olmadan Luxon, sıklıkla İngilizce olarak ayarlanmış olan n8n instance'ının varsayılan dilini kullanır. Instance'ın saat dilimi ve dili birbirinden ayrı iki ayardır, bu yüzden doğru ayarlanmış bir Europe/Berlin tek başına henüz Almanca bir ay adını garanti etmez.

Her tarih için saat dilimini manuel olarak mı ayarlamalıyım?

Bir tarih API, veritabanı veya form gibi harici bir kaynaktan geldiğinde, evet. Bu tür değerler genellikle UTC olarak veya yabancı bir saat diliminde bulunur ve yalnızca $now ya da $today, n8n'de yapılandırılmış instance veya workflow saat dilimini otomatik olarak izler.

Bu, Schedule Trigger veya Cron ifadeleri için de geçerli mi?

Hayır, orada yürütme zamanının kendisi için kendi kuralları geçerlidir, ifadelerdeki tarih değerlerinin biçimlendirilmesi için değil. Bu makale yalnızca bir workflow içinde zaten var olan bir tarihin nasıl doğru biçimlendirildiğini ele alır.

Luxon'un hangi format token'larını desteklediğini nasıl öğrenirim?

Date & Time Node dokümantasyonuna göre n8n, Luxon'un kendisinin de bildiği tüm token'ları destekler; büyük ve küçük harflerin her birinin kendi anlamı vardır. Mevcut tüm token'lara ilişkin eksiksiz bir genel bakış için, doğrudan n8n dokümantasyonundan bağlantı verilen Luxon biçimlendirme referansına göz atmakta fayda var.