DateTime (UTC) ve DateTimeOffset depolama

Genellikle veritabanından / veritabanından okumadan / veritabanına yazmadan hemen önce DateTime dönüşümü yapan (UTC'den yerel saate ve yerel saatten UTC'ye) bir "yakalayıcım" var, böylece DateTime.Nowendişelenmeden sistem genelinde kullanabilirim (türevler ve karşılaştırmalar) saat dilimleri hakkında.

Serileştirme ve bilgisayarlar arasında veri taşıma ile ilgili olarak, tarih saati her zaman UTC olduğundan, uğraşmaya gerek yoktur.

Tarihlerimi (SQL 2008 - datetime) UTC formatında saklamaya devam etmeli miyim yoksa bunun yerine DateTimeOffset(SQL 2008 - datetimeoffset) kullanarak mı depolamalıyım ?

Veritabanındaki UTC Tarihleri ​​(tarih saat türü) çok uzun süredir çalışıyor ve biliniyor, neden değiştirilsin? Avantajları nelerdir?

Zaten gibi eşyalar haline baktım bu bir , ama ben% 100 olsa ikna değilim. Düşüncesi olan var mı?

UTC'yi tek başına kullanamayacağınız çok büyük bir fark var.

• Böyle bir senaryonuz varsa

  • Bir sunucu ve birkaç istemci (tümü coğrafi olarak farklı saat dilimlerinde )
  • İstemciler datetime bilgileriyle bazı veriler oluşturur
  • İstemciler hepsini merkezi sunucuda depolar

• Sonra:

  • datetimeoffset, istemcinin Yerel saatini ve AYRICA UTC saatine uzaklığı depolar
  • tüm müşteriler tüm verilerin UTC saatini ve ayrıca bilginin geldiği yerdeki yerel saati bilir.

• Fakat:

  • UTC tarih saati yalnızca UTC tarih saatini depolar , bu nedenle verilerin geldiği istemci konumundaki yerel saat hakkında bilgi sahibi olmazsınız.
  • Diğer müşteriler, tarih saat bilgilerinin geldiği yerin yerel saatini bilmiyor
  • Diğer müşteriler, verilerin geldiği müşterinin yerel saatini değil, yalnızca veritabanından (UTC saatini kullanarak) yerel saatlerini hesaplayabilir.

Basit bir örnek, uçak bileti rezervasyon sistemidir ... Uçak bileti 2 kez içermelidir: - "kalkış" zamanı ("Kalkış" şehrin saat diliminde) - "iniş" zamanı ("Varış noktası" şehrin saat diliminde)

UTC'yi tüm geçmiş zamanlar için kullanmakta kesinlikle haklısınız (yani gerçekleşen olayları kaydetme). UTC'den yerel saate gitmek her zaman mümkündür, ancak her zaman tam tersi olmayabilir.

Yerel saat ne zaman kullanılır? Bu soruyu cevaplayın:

Hükümet birdenbire gün ışığından yararlanma tasarrufunu değiştirmeye karar verirse, bu verilerin de değişmesini ister misiniz?

Yerel saati yalnızca yanıt "evet" ise kaydedin. Açıkçası, bu yalnızca gelecekteki tarihler için ve genellikle yalnızca insanları bir şekilde etkileyen tarihler için olacaktır.

Neden bir saat dilimi / fark saklanmalı?

İlk olarak, eylemi gerçekleştiren kullanıcı için ofsetin ne olduğunu kaydetmek istiyorsanız, muhtemelen en iyisi bunu yapmaktır, yani oturum açarken o kullanıcının yerini ve saat dilimini kaydedin.

İkincisi, görüntüleme için dönüştürmek istiyorsanız, o zaman dilimi için tüm yerel saat farkı geçişlerinin bir tablosuna sahip olmanız gerekir, sadece mevcut farkın yeterli olmadığını bilmeniz yeterli, çünkü altı ay öncesine ait bir tarih / saat gösteriyorsanız, fark farklı ol.

DATETIMEOFFSET, yerel saati ve UTC saatini tek bir alanda saklama yeteneği sağlar.

Bu, verileri herhangi bir şekilde görüntülemek için işlemeye gerek kalmadan yerel veya UTC saatinde çok basit ve verimli raporlama sağlar.

Bunlar en yaygın iki gereksinimdir - yerel raporlar için yerel saat ve grup raporları için UTC saati.

Yerel saat, DATETIMEOFFSET'in DATETIME bölümünde saklanır ve UTC'den OFFSET, OFFSET bölümünde saklanır, bu nedenle dönüştürme basittir ve verilerin geldiği saat dilimi hakkında bilgi gerektirmediğinden, tümü veritabanı düzeyinde yapılabilir. .

Milisaniyeye kadar olan sürelere ihtiyaç duymuyorsanız, örneğin sadece dakikalara veya saniyelere, DATETIMEOFFSET (0) kullanabilirsiniz. DATETIMEOFFSET alanı bu durumda yalnızca 8 bayt depolama gerektirir - DATETIME ile aynıdır.

Bu nedenle, UTC DATETIME yerine DATETIMEOFFSET kullanmak, raporlama için daha fazla esneklik, verimlilik ve basitlik sağlar.