Cevap

SQL'de tarih ve aralıklarla çalışmak için birçok işlev bulunmaktadır: DATEDIFF, DATEADD (T-SQL), INTERVAL tipi ile çalışma (PostgreSQL), farklı zaman dilimlerine geçişler için işlevsellik (AT TIME ZONE). Tarihlerle doğru bir şekilde çalışabilmek için, esas olarak zaman dilimini dikkate alan veri türlerini kullanmak önemlidir (TIMESTAMP WITH TIME ZONE, timestamptz), sadece DATE veya DATETIME kullanmak yeterli değildir, özellikle küresel hizmetlerde.

Farklı DBMS'lerde sözdizimi ve çalışma özellikleri değişiklik göstermektedir:

SQL Server: DATEDIFF, DATEADD, FORMAT, ancak tam anlamıyla INTERVAL yoktur. Zaman dilimleri açıkça düzenlenmektedir.
PostgreSQL: INTERVAL desteği, birçok işlev (+/- INTERVAL), zaman dilimlerinin doğrudan yönetimi.

Hatalar genellikle UTC/yerel zaman arasında tutarsızlıklar ve farklılıkları dikkate almayan işlemler nedeniyle ortaya çıkmaktadır.

Zaman farkı hesaplama örneği (PostgreSQL)

SELECT
  EXTRACT(EPOCH FROM (event_end AT TIME ZONE 'UTC' - event_start AT TIME ZONE 'UTC')) / 3600 AS hours
FROM events

Kandırmacalı soru

DATEDIFF fonksiyonunda tarih farkı negatif bir sayı verebilir mi ve bu durumda tarihlerin sırası ne anlama gelir?

Cevap: Evet, DATEDIFF (DATEDIFF(day, d1, d2)) negatif bir sayı döndürür, eğer d2 < d1 ise. Parametrelerin sırasını karıştırmamak önemlidir: önce ölçüm birimi, sonra başlangıç tarihi, en son olarak bitiş tarihi gelir.

Örnek:

SELECT DATEDIFF(day, '2024-05-01', '2024-04-25') -- -6 döndürür

Gerçek hata örnekleri

Hikaye

Küresel kullanıcıların bulunduğu projede, raporlar her bölgedeki sunucuların yerel zamanına göre oluşturuluyordu. Sonuç olarak, tarihlerde uyumsuzluklar ve başka zaman dilimlerinden gelen kullanıcılar için gün ortasında "delikler" oluştu. Sorun, tüm zaman verilerinin UTC'ye dönüştürülmesi ve yalnızca görüntüleme için yeniden hesaplanmasıyla çözüldü.

Hikaye

DATEDIFF ile abone sürelerini hesaplarlarken tarihlerin sırasını karıştırdık. Sonuç olarak bazı kullanıcılar yanlışlıkla "aşırı kullanıcılar" olarak değerlendirildi, geçmişleri bilerek negatif sayılar oldu. Sorun, tarihlerin sırası kontrol edilerek düzeltildi.

Hikaye

Geliştirici, zaman dilimini göz önünde bulundurmaksızın DATETIME değerlerini sakladı, PostgreSQL'e geçişte değerler UTC olarak yorumlandı, oysa başlangıçta GMT+3'tü, bu da raporlardaki olayların 3 saat geriye kaymasına neden oldu. Sonuç olarak, her zaman tarihleri zaman dilimi dikkate alarak saklamak ve dönüştürmek gereklidir!