SQL Server has several functions that return the current date and time. If you just need today’s date for a query, that sounds like it should be simple. And it is. But there are six different functions to choose from, and they don’t all return the same thing. This article explains what each one does and when to use it.
The Functions at a Glance
Here’s a quick overview before we dig in:
| Function | Returns | Data Type |
|---|---|---|
GETDATE() | Local date and time | datetime |
CURRENT_TIMESTAMP | Local date and time | datetime |
SYSDATETIME() | Local date and time (higher precision) | datetime2(7) |
GETUTCDATE() | UTC date and time | datetime |
SYSUTCDATETIME() | UTC date and time (higher precision) | datetime2(7) |
SYSDATETIMEOFFSET() | Local date and time with UTC offset | datetimeoffset(7) |
All of these functions read from the operating system clock of the server running SQL Server. When you see references to “local time” below, that means the server’s local time, not yours. If the server is in a different time zone to you or your users, the results may not match what you’d expect.
The main differences come down to precision, time zone, and data type. We’ll cover each function individually below.
GETDATE()
The GETDATE() function is probably the most popular option for returning the current date. And for good reason. It’s simple, widely supported, and works in every version of SQL Server.
SELECT GETDATE();Example result:
2026-03-25 02:58:14.827
It returns the current local date and time as a datetime value, with precision to the millisecond. For most everyday use cases (e.g. logging, filtering by date, stamping a record with a created time) GETDATE() is all you need.
CURRENT_TIMESTAMP
CURRENT_TIMESTAMP returns exactly the same value as GETDATE(). Same data type, same precision, same result:
SELECT CURRENT_TIMESTAMP;Result:
2026-03-25 02:58:14.827
The only difference is that CURRENT_TIMESTAMP is the ANSI SQL standard, which means it works across other database systems too. If you’re writing SQL that might need to run on PostgreSQL or MySQL down the line, using CURRENT_TIMESTAMP is the more portable choice. Otherwise, GETDATE() and CURRENT_TIMESTAMP are interchangeable.
SYSDATETIME()
SYSDATETIME() also returns the local date and time, but with higher precision than GETDATE():
SELECT SYSDATETIME();Result:
2026-03-25 02:58:14.8358517
The data type is datetime2(7), which gives you precision down to 100 nanoseconds. That’s seven decimal places on the seconds instead of the three that the datetime type provides. For most applications, that level of precision doesn’t matter at all. But if you’re building something where timing accuracy is critical, like benchmarking, event sequencing, or financial transaction logging, SYSDATETIME() is the better pick.
GETUTCDATE()
This one returns the current date and time in UTC rather than the server’s local time:
SELECT GETUTCDATE();Output:
2026-03-25 02:58:14.867
If your server is in a different time zone to your users, or if your application serves people in multiple time zones, storing dates in UTC is generally the right approach. It avoids all the headaches around daylight saving time and makes it much easier to convert to any local time zone later. GETUTCDATE() is the equivalent of GETDATE() but in UTC. Same datetime data type, same millisecond precision.
SYSUTCDATETIME()
Exactly what it sounds like: the UTC equivalent of SYSDATETIME(). You get the current UTC date and time, but with the higher datetime2(7) precision:
SELECT SYSUTCDATETIME();Result:
2026-03-25 02:58:14.8685631
Use this when you need UTC timestamps and precision matters. Otherwise GETUTCDATE() is usually sufficient.
SYSDATETIMEOFFSET()
This one is a bit different. It returns the current local date and time along with the UTC offset, so you can see both the local time and how far it sits from UTC.
SELECT SYSDATETIMEOFFSET();Result:
2026-03-25 02:58:14.8685631 +00:00
The data type is datetimeoffset(7), which is the only SQL Server data type that stores time zone offset information as part of the value itself. This is useful when your application needs to record not just when something happened, but where (in time zone terms) it happened. It’s the most complete timestamp you can store.
That said, it’s also the most complex to work with. If you don’t have a specific need for offset-aware timestamps, stick with one of the simpler functions.
Which One Should You Use?
With so many functions to get the current date, it would be understandable if you’re scratching your head over the best one to use. Here’s a practical way to decide:
- For most everyday queries and record stamping,
GETDATE()is fine. It’s familiar, readable, and well-supported. - If you care about SQL portability across different database systems, use
CURRENT_TIMESTAMPinstead. It does the same thing but follows the ANSI standard. - If your application is time zone-aware or serves users in multiple regions, store timestamps in UTC using
GETUTCDATE(). - If you need higher precision (sub-millisecond accuracy), swap to the
SYS-variants:SYSDATETIME()for local time orSYSUTCDATETIME()for UTC. - If you need to store the time zone offset alongside the timestamp, use
SYSDATETIMEOFFSET().
Getting Just the Date Without the Time
All six functions return a date and time combined. If you only want today’s date with no time component, you can wrap the function in a CAST():
SELECT CAST(GETDATE() AS DATE);Result:
2026-03-25
This works with any of the functions above. The result is a plain date value. No hours, no minutes, no seconds.
This is handy when filtering records by date, since comparing a datetime column to a date-only value can produce unexpected results if you’re not careful about the time portion.
Using the Current Date in a WHERE Clause
A common reason to grab the current date is to filter query results. Here are a few examples:
-- Records created today
SELECT * FROM orders
WHERE CAST(order_date AS DATE) = CAST(GETDATE() AS DATE);
-- Records created in the last 7 days
SELECT * FROM orders
WHERE order_date >= DATEADD(DAY, -7, GETDATE());
-- Records created this month
SELECT * FROM orders
WHERE MONTH(order_date) = MONTH(GETDATE())
AND YEAR(order_date) = YEAR(GETDATE());The DATEADD() function in the second example lets you do date arithmetic (in this case, subtracting 7 days from today to get a rolling 7-day window). It’s worth getting familiar with if you’re writing date-based queries regularly.