Typy danych daty i czasu obejmują DATE, TIME, DATETIME2 i inne warianty o różnej precyzji i zakresie.
Jak SQL Server przechowuje datę i czas
W systemie Microsoft SQL Server typy daty i czasu określają nie tylko sposób wyświetlania wartości, lecz także jej zakres, dokładność oraz ilość zajmowanego miejsca. Najczęściej stosuje się typy date, time, datetime2, datetime, smalldatetime, datetimeoffset oraz starszy typ timestamp, który w SQL Server nie przechowuje daty ani godziny. Ostatni z wymienionych jest synonimem typu rowversion i służy do oznaczania zmian w wierszach.
Typ date zapisuje wyłącznie datę kalendarzową w zakresie od 1 stycznia 0001 roku do 31 grudnia 9999 roku. Nie zawiera godziny, minut ani sekund i zajmuje 3 bajty. Typ time przechowuje samą porę dnia od 00:00:00 do 23:59:59.9999999. Jego precyzję określa parametr skali od 0 do 7, na przykład time(0) zapisuje sekundy bez części ułamkowej, a time(7) pozwala przechować siedem cyfr po separatorze dziesiętnym.
Precyzja i zakres typu datetime2
datetime2 jest typem przeznaczonym do przechowywania daty i czasu bez informacji o przesunięciu względem UTC. Występuje ze skalą od 0 do 7, a więc może przechowywać czas od dokładności jednej sekundy do dokładności deklarowanej przez siedem cyfr części ułamkowej sekundy. Zakres wartości obejmuje daty od 0001-01-01 do 9999-12-31 oraz czas do 23:59:59.9999999. Wymiar przechowywania zależy od skali: dla skal 0–2 używane jest 6 bajtów, dla skal 3–4 7 bajtów, a dla skal 5–7 8 bajtów.
Typ datetime ma stały rozmiar 8 bajtów i zakres od 1753-01-01 do 9999-12-31. Jego część czasowa nie odwzorowuje każdej wartości z dokładnością jednej milisekundy. SQL Server zaokrągla ułamki sekund do wartości odpowiadających między innymi końcówkom .000, .003 i .007 sekundy. Z tego powodu datetime2 jest właściwszym wyborem dla nowych tabel, gdy aplikacja wymaga przewidywalnej precyzji albo obsługi dat wcześniejszych niż rok 1753. Typ smalldatetime zajmuje 4 bajty, obejmuje lata 1900–2079 i przechowuje czas z dokładnością do minuty; sekundy są zaokrąglane do najbliższej minuty.
Jeżeli wartość musi zawierać również strefowe przesunięcie czasu, stosuje się datetimeoffset. Typ ten przechowuje datę, godzinę i przesunięcie w zakresie od -14:00 do +14:00. Wartość datetimeoffset nie jest jednak nazwą strefy czasowej i nie zawiera reguł zmian czasu letniego. Przesunięcie +01:00 nie określa samodzielnie, czy dana lokalizacja przechodzi na +02:00 w okresie letnim.
Dobór typu w tabelach i zapytaniach
Wybór typu powinien wynikać z znaczenia pola. Dla daty urodzenia, dnia wystawienia dokumentu albo terminu płatności zwykle wystarcza date. Dla godziny rozpoczęcia pracy, czasu trwania zdarzenia zapisanego jako pora dnia albo harmonogramu dziennego można wykorzystać time. Dla lokalnego momentu zdarzenia, który ma być przechowywany bez przesunięcia strefowego, odpowiedni jest datetime2. Jeżeli system obsługuje zdarzenia pochodzące z wielu stref czasowych, informacja o przesunięciu może być istotna i wtedy należy rozważyć datetimeoffset.
Parametr skali powinien odpowiadać wymaganej dokładności, ponieważ większa precyzja może zwiększyć rozmiar wartości i wpływać na indeksy. Jeśli aplikacja rejestruje zdarzenia z dokładnością do sekund, deklaracja datetime2(0) jest jednoznaczniejsza niż pozostawienie domyślnej skali. Dla znaczników technicznych, które muszą rozróżniać operacje wykonywane w krótkim odstępie czasu, można użyć wyższej skali. Nie należy jednak traktować części ułamkowej jako gwarancji dokładności pomiaru zegara systemowego; typ określa format przechowywania, a nie jakość źródła czasu.
Literały daty i czasu powinny być przekazywane w sposób odporny na ustawienia języka i formatu daty sesji. W praktyce parametry zapytań są bezpieczniejsze od sklejania tekstu SQL z wartościami pochodzącymi z interfejsu. Konwersje między typami mogą obcinać część ułamkową, zaokrąglać czas albo usuwać przesunięcie strefowe. Szczególną uwagę należy zwrócić na porównania wartości z różnymi skalami oraz na niejawne konwersje w warunkach WHERE, ponieważ mogą zmienić wynik filtrowania lub ograniczyć możliwość użycia indeksu.
Diagnostyka błędów związanych z datą i czasem
Typowe problemy wynikają z pomieszania daty lokalnej, czasu UTC i przesunięcia strefowego. Sam zapis tekstowy 2026-08-24 14:30:00 nie informuje, w jakiej strefie wykonano pomiar. Jeżeli kolumna ma typ datetime2, aplikacja musi mieć ustaloną konwencję interpretacji tej wartości. Jeżeli przesunięcie ma znaczenie biznesowe lub audytowe, powinno być przechowywane w danych, a nie odtwarzane później na podstawie ustawień komputera użytkownika.
Podczas diagnostyki należy sprawdzić definicję kolumny, typ parametrów procedur, sposób serializacji w aplikacji oraz wartości pośrednie na granicy systemu. Warto testować daty z początku i końca zakresu, północ, zmianę dnia, sekundy z częścią ułamkową oraz przejście między czasem standardowym i letnim. Należy także rozróżnić błąd walidacji od utraty precyzji: odrzucenie daty spoza zakresu jest innym problemem niż zapis wartości datetime2(7) do kolumny o mniejszej skali.
W środowiskach wykorzystujących SQL Server kontrola powinna obejmować również zapytania sortujące i filtrujące po czasie. Warunek oparty na przedziale półotwartym, na przykład od chwili początkowej włącznie do chwili końcowej wyłącznie, ogranicza ryzyko pomijania rekordów na granicy okresu. Przy analizie awarii trzeba zachować oryginalną wartość, typ kolumny i informację o strefie, ponieważ sam sformatowany tekst może ukryć zaokrąglenie, konwersję albo różnicę między czasem lokalnym i UTC.
