Sql server datediff — kompletny przewodnik 2026

SQL Server DATEDIFF to funkcja języka T-SQL służąca do obliczania różnicy między dwiema datami lub wartościami czasu. Zwraca liczbę przekroczonych granic wskazanej jednostki, na przykład dni, miesięcy, lat, godzin albo sekund. W praktyce jest jedną z najczęściej używanych funkcji daty w Microsoft SQL Server, ponieważ pozwala liczyć wiek klienta, czas realizacji zamówienia, liczbę dni opóźnienia faktury, okres aktywności konta, długość sesji użytkownika czy różnicę między datą wystawienia i terminem płatności.

Najważniejsze jest to, że DATEDIFF nie mierzy „pełnego czasu trwania” w intuicyjnym sensie, tylko liczy, ile granic wybranej części daty zostało przekroczonych między datą początkową a końcową. Dlatego różnica między 2026-01-31 i 2026-02-01 wynosi 1 miesiąc, mimo że minął tylko jeden dzień. To zachowanie jest poprawne, ale bywa źródłem błędów w raportach, fakturowaniu, SLA i systemach kadrowych.

W 2026 roku funkcja DATEDIFF pozostaje aktualna w SQL Server 2022, Azure SQL Database, Azure SQL Managed Instance oraz środowiskach działających na Windows Server 2025. Jeśli firma modernizuje infrastrukturę, migruje bazę danych lub kupuje licencję SQL Server do systemu ERP, CRM albo raportowania BI, zrozumienie DATEDIFF jest praktyczne nie tylko dla programisty, ale również dla osoby odpowiedzialnej za poprawność danych biznesowych. Przy wdrożeniach produkcyjnych warto korzystać z legalnych licencji — przykładowo licencje Microsoft SQL Server można kupić na KluczeSoft.pl z fakturą VAT 23% i szybką dostawą cyfrową: sprawdź klucze SQL Server na kluczesoft.pl.

Co robi SQL Server DATEDIFF i kiedy go używać?

Funkcja DATEDIFF oblicza różnicę między startdate i enddate w wybranej jednostce czasu. Składnia jest prosta:

DATEDIFF(datepart, startdate, enddate)

Gdzie:

• datepart — jednostka, w której ma zostać zwrócona różnica, np. day, month, year, hour;
• startdate — data początkowa;
• enddate — data końcowa.

Przykład:

SELECT DATEDIFF(day, '2026-01-01', '2026-01-10') AS LiczbaDni;

Wynik:

9

Jeżeli enddate jest późniejsza niż startdate, wynik jest dodatni. Jeżeli enddate jest wcześniejsza, wynik jest ujemny:

SELECT DATEDIFF(day, '2026-01-10', '2026-01-01') AS LiczbaDni;

Wynik:

-9

Najczęstsze zastosowania DATEDIFF w firmowych bazach danych:

• raportowanie sprzedaży — liczba dni od zamówienia do płatności;
• windykacja i należności — dni opóźnienia względem terminu płatności;
• systemy HR — staż pracy, wiek pracownika, liczba dni urlopu;
• SLA i helpdesk — czas obsługi zgłoszenia w godzinach lub minutach;
• e-commerce — czas od rejestracji klienta do pierwszego zakupu;
• analityka użytkowników — długość sesji, retencja, aktywność w ostatnich 30 dniach;
• integracje ERP/CRM — filtrowanie dokumentów według okresów rozliczeniowych.

Kluczowa zasada: DATEDIFF zwraca liczbę przekroczonych granic jednostki, a nie zawsze pełną liczbę zakończonych okresów. To ma znaczenie szczególnie przy year, quarter, month, week i day.

Przykład z miesiącem:

SELECT DATEDIFF(month, '2026-01-31', '2026-02-01') AS RoznicaMiesiecy;

Wynik:

1

Dlaczego? Ponieważ między datami przekroczono granicę miesiąca — z stycznia na luty. DATEDIFF nie pyta, czy upłynął pełny miesiąc kalendarzowy.

Składnia DATEDIFF, jednostki datepart i typy danych

DATEDIFF obsługuje wiele jednostek czasu. Można używać pełnych nazw albo skrótów. W praktyce warto stosować pełne nazwy w kodzie produkcyjnym, ponieważ są czytelniejsze dla zespołu i mniej podatne na pomyłki.

Ważne: weekday w DATEDIFF nie liczy dni roboczych. Działa jak licznik przekroczeń granic dni, podobnie jak day, a nie jako kalendarz „poniedziałek–piątek”. Jeśli potrzebujesz liczby dni roboczych, trzeba użyć tabeli kalendarza, reguł świąt i weekendów albo osobnej logiki biznesowej.

DATEDIFF przyjmuje typy daty i czasu używane w SQL Server, między innymi:

• date;
• time;
• datetime;
• datetime2;
• smalldatetime;
• datetimeoffset.

Najlepszą praktyką w nowych systemach jest używanie datetime2 zamiast starszego datetime, ponieważ oferuje większą precyzję i szerszy zakres wartości. Dla samej daty bez czasu często wystarczy date. Dla danych z różnych stref czasowych warto rozważyć datetimeoffset, ale trzeba wtedy świadomie kontrolować konwersje i przesunięcia.

Przykład z różnicą godzin:

SELECT DATEDIFF(hour, '2026-03-01 08:00:00', '2026-03-01 17:30:00') AS Godziny;

Wynik:

9

Funkcja zwraca 9, ponieważ przekroczono granice godzin od 8 do 17. Nie dostaniesz wartości 9,5 — DATEDIFF zwraca liczbę całkowitą. Jeśli potrzebujesz wyniku dziesiętnego, licz w mniejszych jednostkach i przeliczaj:

SELECT DATEDIFF(minute, '2026-03-01 08:00:00', '2026-03-01 17:30:00') / 60.0 AS GodzinyDziesietne;

Wynik:

9.500000

To szczególnie ważne przy rozliczaniu czasu pracy, usług serwisowych, billingów godzinowych i SLA.

DATEDIFF a DATEDIFF_BIG — różnice, limity i wybór w 2026

Standardowa funkcja DATEDIFF zwraca typ int. To oznacza, że wynik musi zmieścić się w zakresie od -2 147 483 648 do 2 147 483 647. W większości raportów dziennych, miesięcznych i rocznych to wystarcza. Problem pojawia się przy bardzo drobnych jednostkach, takich jak milisekundy, mikrosekundy i nanosekundy, albo przy bardzo długich okresach.

Dla takich przypadków SQL Server udostępnia DATEDIFF_BIG, który działa podobnie, ale zwraca typ bigint.

Składnia:

DATEDIFF_BIG(datepart, startdate, enddate)

Porównanie:

Przykład, w którym DATEDIFF_BIG jest bezpieczniejszy:

SELECT DATEDIFF_BIG(millisecond, '2000-01-01', '2026-01-01') AS Milisekundy;

W systemach produkcyjnych z dużą ilością logów, danych IoT, integracji API lub monitoringu aplikacji DATEDIFF_BIG jest często lepszym wyborem, ponieważ eliminuje ryzyko przepełnienia. Dotyczy to szczególnie hurtowni danych, systemów eventowych i analityki zachowań użytkowników.

Nie oznacza to jednak, że trzeba zawsze zastępować DATEDIFF wersją BIG. Jeśli liczysz różnicę w dniach między datą faktury a datą płatności, DATEDIFF(day, ...) jest czytelne i wystarczające. Jeżeli liczysz różnicę w mikrosekundach między zdarzeniami systemowymi z kilku lat, użyj DATEDIFF_BIG.

W 2026 roku, przy środowiskach SQL Server 2022 i Azure SQL, oba warianty są standardowo dostępne. Warto jednak zadbać, aby aplikacja, raport Power BI, procedura ETL lub warstwa ORM poprawnie obsługiwały typ wyniku. bigint może wymagać innego mapowania niż int, zwłaszcza w starszych aplikacjach .NET, integracjach ODBC lub raportach eksportowanych do Excela.

Przykłady DATEDIFF w zapytaniach biznesowych

DATEDIFF jest najbardziej wartościowy wtedy, gdy rozwiązuje konkretne problemy biznesowe. Poniżej znajdują się przykłady, które często pojawiają się w systemach sprzedaży, księgowości, HR i obsługi klienta.

Liczba dni opóźnienia faktury

SELECT
    NumerFaktury,
    TerminPlatnosci,
    DataPlatnosci,
    DATEDIFF(day, TerminPlatnosci, DataPlatnosci) AS DniOpoznienia
FROM Faktury
WHERE DataPlatnosci > TerminPlatnosci;

Jeżeli faktura miała termin płatności 2026-05-10, a zapłacono ją 2026-05-15, wynik wyniesie 5. W polskich realiach księgowych takie raporty są przydatne przy monitorowaniu należności, przygotowaniu zestawień dla działu finansów oraz integracji z systemami zgodnymi z KSeF.

Otwarte faktury po terminie

SELECT
    NumerFaktury,
    Kontrahent,
    KwotaBrutto,
    TerminPlatnosci,
    DATEDIFF(day, TerminPlatnosci, GETDATE()) AS DniPoTerminie
FROM Faktury
WHERE DataPlatnosci IS NULL
  AND TerminPlatnosci < CAST(GETDATE() AS date);

To typowe zapytanie windykacyjne. Warto zauważyć użycie CAST(GETDATE() AS date), aby ograniczyć wpływ części godzinowej przy porównaniach z kolumną typu date.

Czas realizacji zamówienia

SELECT
    ZamowienieId,
    DataZlozenia,
    DataWysylki,
    DATEDIFF(hour, DataZlozenia, DataWysylki) AS CzasRealizacjiGodziny
FROM Zamowienia
WHERE DataWysylki IS NOT NULL;

Jeżeli firma mierzy SLA w godzinach, taki raport pokazuje, które zamówienia przekroczyły ustalony próg. Dla dokładniejszych wyników można liczyć minuty i dzielić przez 60.0.

Wiek klienta lub pracownika

Prosty wariant:

SELECT
    Imie,
    Nazwisko,
    DATEDIFF(year, DataUrodzenia, GETDATE()) AS Wiek
FROM Klienci;

Ten przykład jest popularny, ale nie zawsze poprawny. DATEDIFF(year, ...) liczy przekroczenie granicy roku, więc może zawyżyć wiek przed urodzinami w danym roku. Bezpieczniejsza wersja:

SELECT
    Imie,
    Nazwisko,
    DATEDIFF(year, DataUrodzenia, CAST(GETDATE() AS date))
      - CASE
          WHEN DATEADD(year, DATEDIFF(year, DataUrodzenia, CAST(GETDATE() AS date)), DataUrodzenia) > CAST(GETDATE() AS date)
          THEN 1
          ELSE 0
        END AS Wiek
FROM Klienci;

To przykład, który dobrze pokazuje różnicę między „różnicą lat” a realnym wiekiem.

Klienci aktywni w ostatnich 30 dniach

Często spotykany, ale mniej optymalny zapis:

SELECT *
FROM Klienci
WHERE DATEDIFF(day, OstatniaAktywnosc, GETDATE()) <= 30;

Lepiej napisać:

SELECT *
FROM Klienci
WHERE OstatniaAktywnosc >= DATEADD(day, -30, GETDATE());

Drugi wariant jest zwykle korzystniejszy dla wydajności, ponieważ pozwala SQL Server lepiej wykorzystać indeks na kolumnie OstatniaAktywnosc.

Wydajność, indeksy i dobre praktyki w SQL Server

DATEDIFF może wyglądać niewinnie, ale użyty w niewłaściwym miejscu potrafi spowolnić zapytania na dużych tabelach. Najczęstszy problem polega na stosowaniu funkcji bezpośrednio na kolumnie filtrowanej w WHERE.

Nieoptymalny przykład:

SELECT *
FROM Zamowienia
WHERE DATEDIFF(day, DataZlozenia, GETDATE()) <= 7;

Taki zapis wymusza obliczenie DATEDIFF dla wielu wierszy. SQL Server może mieć trudność z efektywnym użyciem indeksu na DataZlozenia, ponieważ kolumna jest opakowana funkcją.

Lepszy zapis:

SELECT *
FROM Zamowienia
WHERE DataZlozenia >= DATEADD(day, -7, GETDATE());

To podejście jest bardziej SARGable, czyli przyjazne dla mechanizmu wyszukiwania po indeksach. Zamiast liczyć różnicę dla każdego rekordu, SQL Server porównuje kolumnę z konkretną wartością graniczną.

Najważniejsze dobre praktyki:

• nie opakowuj kolumny daty funkcją w WHERE, jeśli można porównać ją do wartości obliczonej;
• licz różnice w SELECT, gdy są elementem wyniku raportu;
• filtruj zakresami dat, szczególnie na dużych tabelach transakcyjnych;
• używaj DATEADD do wyznaczania granic, np. ostatnie 7, 30 lub 365 dni;
• dobieraj typ danych świadomie — date dla samej daty, datetime2 dla daty z czasem;
• unikaj niejednoznacznych formatów dat, takich jak 01/02/2026;
• stosuj format ISO, np. 2026-02-01 albo dla pełnej daty i czasu 2026-02-01T14:30:00.

Porównanie typowych zapisów:

W raportach miesięcznych warto wyliczyć granice okresu jawnie:

DECLARE @Start date = '2026-05-01';
DECLARE @End date = DATEADD(month, 1, @Start);

SELECT *
FROM Sprzedaz
WHERE DataSprzedazy >= @Start
  AND DataSprzedazy < @End;

Taki zapis działa poprawnie niezależnie od godziny transakcji. Nie trzeba martwić się rekordami z 2026-05-31 23:59:59.997, precyzją datetime ani zmianą typu kolumny na datetime2.

Najczęstsze pułapki: miesiące, lata, tygodnie i strefy czasowe

Najwięcej błędów z DATEDIFF dotyczy jednostek, które ludzie interpretują biznesowo, a SQL Server interpretuje technicznie. Dotyczy to zwłaszcza lat, miesięcy i tygodni.

Pierwsza pułapka to liczenie wieku przez DATEDIFF(year). Jak pokazano wcześniej, sama różnica lat może zawyżyć wynik. Jeżeli klient urodził się 2000-12-31, a dziś jest 2026-01-01, DATEDIFF(year, DataUrodzenia, GETDATE()) zwróci 26, mimo że osoba ma jeszcze 25 lat. W systemach ubezpieczeniowych, medycznych, kadrowych i finansowych taki błąd może mieć konsekwencje formalne.

Druga pułapka to miesiące rozliczeniowe. DATEDIFF(month, 2026-01-31, 2026-02-01) zwraca 1, ale nie oznacza pełnego miesiąca korzystania z usługi. Jeśli firma nalicza abonament proporcjonalnie, trzeba oprzeć kalkulację na liczbie dni, regułach fakturowania albo specjalnym kalendarzu rozliczeniowym.

Trzecia pułapka to tygodnie. DATEDIFF(week, ...) liczy przekroczenia granic tygodnia według reguł SQL Server, a niekoniecznie według oczekiwań raportu biznesowego. Jeśli firma raportuje tygodnie ISO, tygodnie handlowe lub okresy od poniedziałku do niedzieli, należy to jasno zdefiniować. Dla raportów zarządczych często lepsza jest tabela kalendarza z numerem tygodnia, miesiącem fiskalnym, kwartałem i flagami dni roboczych.

Czwarta pułapka to czas letni i strefy czasowe. W aplikacjach działających globalnie sama różnica godzin między lokalnymi datami może być myląca. Zmiana czasu może sprawić, że doba ma 23 albo 25 godzin. Jeżeli system mierzy realny czas trwania zdarzeń, dobrą praktyką jest przechowywanie znacznika czasu w UTC, a lokalizację stosować dopiero na etapie prezentacji. Przy typie datetimeoffset trzeba dodatkowo rozumieć, jak SQL Server interpretuje przesunięcia.

Piąta pułapka to smalldatetime. Ten typ zaokrągla czas do minuty, więc obliczenia w sekundach lub milisekundach mogą być nieprecyzyjne. W nowoczesnych systemach lepiej wybierać datetime2.

Szósta pułapka to mieszanie daty i czasu. Jeżeli porównujesz date z datetime, SQL Server może domyślnie przyjąć godzinę 00:00:00. W raportach dziennych najlepiej używać przedziałów półotwartych: >= początek oraz < następny_początek.

SQL Server DATEDIFF w zakupie licencji, raportowaniu i utrzymaniu systemów

Choć DATEDIFF jest funkcją programistyczną, jej poprawne użycie ma wymiar zakupowy i operacyjny. Firmy kupujące SQL Server najczęściej robią to nie po to, aby „mieć bazę”, ale aby obsługiwać konkretne procesy: sprzedaż, magazyn, księgowość, produkcję, serwis, HR, analitykę lub raportowanie zarządcze. W każdym z tych obszarów daty decydują o pieniądzach: terminach płatności, naliczaniu rabatów, karach umownych, SLA, odsetkach, urlopach i okresach gwarancyjnych.

Przy wyborze środowiska warto uwzględnić trzy poziomy:

SQL Server 2022 jest nadal kluczową wersją dla firm utrzymujących aplikacje lokalnie, a Azure SQL pozostaje naturalnym wyborem dla systemów chmurowych. W środowiskach desktopowych programiści często pracują na Windows 11 24H2 lub 25H2, natomiast serwery produkcyjne coraz częściej planuje się pod Windows Server 2025. Niezależnie od platformy, kod T-SQL z DATEDIFF powinien być pisany tak, aby był czytelny, testowalny i odporny na niejednoznaczne interpretacje dat.

W projektach biznesowych warto też przygotować zestaw testów dla krytycznych dat:

• koniec miesiąca: 30/31 dzień miesiąca oraz luty;
• rok przestępny, np. 2024-02-29;
• przełom roku;
• zmiana czasu letniego;
• faktury z terminem płatności na dzień wolny;
• użytkownicy z datą urodzenia pod koniec roku;
• rekordy z godziną tuż przed północą.

Jeśli system raportuje dane do księgowości, BI lub kontroli zarządczej, testy dat są równie ważne jak testy kwot. Błąd jednego dnia może zmienić klasyfikację faktury z „w terminie” na „po terminie”, a błąd jednego miesiąca może zafałszować przychód okresowy.

Częste pytania

Co oznacza DATEDIFF w SQL Server?

DATEDIFF to funkcja T-SQL, która zwraca różnicę między dwiema datami w wybranej jednostce, na przykład w dniach, miesiącach, latach, godzinach lub minutach. Składnia to DATEDIFF(datepart, startdate, enddate). Funkcja liczy przekroczenia granic danej jednostki, dlatego jej wynik nie zawsze oznacza pełny zakończony okres.

Dlaczego DATEDIFF(month, '2026-01-31', '2026-02-01') zwraca 1?

Ponieważ między tymi datami została przekroczona granica miesiąca — ze stycznia do lutego. DATEDIFF nie sprawdza, czy minął pełny miesiąc kalendarzowy. Liczy zmianę wskazanej części daty. To poprawne zachowanie SQL Server, ale trzeba je uwzględnić w rozliczeniach abonamentów, czynszów, usług cyklicznych i raportach miesięcznych.

Jak policzyć liczbę dni między dwiema datami?

Najprościej użyć DATEDIFF(day, DataOd, DataDo). Przykład: SELECT DATEDIFF(day, '2026-01-01', '2026-01-10') zwróci 9. Jeśli kolumny zawierają również czas, wynik nadal zależy od przekroczeń granic dnia, a nie od pełnych 24-godzinnych okresów.

Czy DATEDIFF liczy dni robocze?

Nie. DATEDIFF(day, ...) i DATEDIFF(weekday, ...) nie liczą dni roboczych w znaczeniu biznesowym. Nie uwzględniają weekendów, świąt państwowych ani firmowego kalendarza pracy. Do liczenia dni roboczych najlepiej użyć tabeli kalendarza z oznaczeniem dni wolnych i roboczych.

Czym różni się DATEDIFF od DATEDIFF_BIG?

DATEDIFF zwraca int, a DATEDIFF_BIG zwraca bigint. Przy zwykłych różnicach w dniach, miesiącach czy latach najczęściej wystarczy DATEDIFF. Przy dużych zakresach czasu liczonych w milisekundach, mikrosekundach lub nanosekundach bezpieczniejszy jest DATEDIFF_BIG, ponieważ ogranicza ryzyko przepełnienia wyniku.

Jak poprawnie policzyć wiek w SQL Server?

Samo DATEDIFF(year, DataUrodzenia, GETDATE()) może zawyżyć wiek, jeśli urodziny w bieżącym roku jeszcze nie minęły. Poprawny wzór powinien odjąć 1, gdy data urodzin w bieżącym roku jest późniejsza niż dzisiejsza data. W systemach HR, medycznych i finansowych warto stosować pełną formułę z DATEADD oraz warunkiem CASE.

Czy DATEDIFF spowalnia zapytania?

Może spowalniać, jeśli użyjesz go na kolumnie w warunku WHERE, np. WHERE DATEDIFF(day, DataZlozenia, GETDATE()) <= 30. Lepszy zapis to WHERE DataZlozenia >= DATEADD(day, -30, GETDATE()), ponieważ SQL Server może efektywniej użyć indeksu na kolumnie daty.

Jaki format daty jest najbezpieczniejszy w DATEDIFF?

Najbezpieczniej stosować format ISO, np. 2026-02-01 dla daty albo 2026-02-01T14:30:00 dla daty z czasem. Unikaj niejednoznacznych zapisów typu 01/02/2026, ponieważ mogą być różnie interpretowane w zależności od ustawień języka i formatu daty.

Czy DATEDIFF działa w SQL Server 2022 i Azure SQL?

Tak. DATEDIFF działa w SQL Server 2022, Azure SQL Database, Azure SQL Managed Instance oraz innych współczesnych środowiskach Microsoft SQL. Funkcja jest standardowym elementem T-SQL i pozostaje aktualna w zastosowaniach biznesowych w 2026 roku.

Jak liczyć ostatnie 30 dni — DATEDIFF czy DATEADD?

Do filtrowania danych lepiej użyć DATEADD, np. WHERE DataAktywnosci >= DATEADD(day, -30, GETDATE()). DATEDIFF można zostawić do prezentacji wyniku w kolumnie raportu. Taki podział jest czytelniejszy i zwykle wydajniejszy, szczególnie przy dużych tabelach z indeksami na kolumnach dat.

Sprawdź też

• Sql server management studio — kompletny przewodnik 2026
• Ms SQL Server Express — kompletny przewodnik 2026
• SQL Server — kompletny przewodnik 2026
• Sql Server Express — kompletny przewodnik 2026

Potrzebujesz licencji? Microsoft SQL Server — sprawdź ofertę KluczeSoft.pl — legalne klucze, faktura VAT, dostawa e-mail.