A timestamp with seven fractional digits looks more precise than one with three, but appearance does not prove clock accuracy. SYSDATETIME returns datetime2(7), while GETDATE returns the older datetime type with different rounding.
GETDATE and SYSDATETIME Return Different Types
GETDATE returns datetime using the SQL Server machine's current local date and time. CURRENT_TIMESTAMP is the standard spelling for the same datetime-style current timestamp and takes no parentheses. Both lose the finer fractional representation available in datetime2.
SYSDATETIME returns the local value as datetime2(7). SYSUTCDATETIME returns UTC as datetime2(7). SYSDATETIMEOFFSET returns the local value with its offset as datetimeoffset(7). The offset expresses how that value relates to UTC, not a full named time-zone history.
Run the next query to inspect values and type metadata on your own instance. These calls are observations of a changing clock, not a single conversion of one captured instant. Do not interpret small differences among columns as a measured accuracy comparison between functions.
SELECT GETDATE() AS CurrentDatetime,
CURRENT_TIMESTAMP AS StandardCurrentTimestamp,
SYSDATETIME() AS LocalDatetime2,
SYSUTCDATETIME() AS UtcDatetime2,
SYSDATETIMEOFFSET() AS LocalDatetimeOffset;
SELECT
SQL_VARIANT_PROPERTY(GETDATE(), 'BaseType') AS GetdateType,
SQL_VARIANT_PROPERTY(CURRENT_TIMESTAMP, 'BaseType') AS CurrentTimestampType,
SQL_VARIANT_PROPERTY(SYSDATETIME(), 'BaseType') AS SysdatetimeType,
SQL_VARIANT_PROPERTY(SYSUTCDATETIME(), 'Scale') AS UtcScale,
SQL_VARIANT_PROPERTY(SYSDATETIMEOFFSET(), 'BaseType') AS OffsetType;Precision Describes Representation
datetime2(7) represents fractional seconds in seven decimal places. Its storage precision permits increments of one hundred nanoseconds. The operating system clock's actual accuracy and resolution depend on the hardware and Windows implementation. More stored digits do not certify that each digit describes an independently accurate measurement.
I separate those two questions when reviewing event timestamps. What can the column represent? How accurately does the host clock track real time? They require different evidence. A beautifully formatted timestamp is still reading the clock attached to that server.
Clock synchronization also matters when comparing different machines. SQL Server cannot repair a drifting operating system clock by choosing a wider type. UTC standardizes the reference frame, while synchronization establishes how closely each host follows that frame. Keep both requirements in the operational design.
Datetime Rounds to Its Own Grid
datetime stores time with approximately one-three-hundredth-second granularity. Displayed fractional endings follow a repeating pattern including .000, .003, and .007. It does not store every possible millisecond value. Converting a more precise datetime2 value can round it to that grid.
The following example uses explicit input strings to show the conversion rule. These are deliberate test values, not measured clock samples. Inspect the datetime output beside the datetime2 input. Near a day boundary, rounding can even move the result into the following date.
Do not fix that behavior by formatting more digits around datetime. The original information has already been rounded. Choose the appropriate storage type before inserting the timestamp. A wider display cannot recover precision that the column never retained.
SELECT s.InputText,
CONVERT(datetime2(7), s.InputText, 126) AS OriginalDatetime2,
CONVERT(datetime, CONVERT(datetime2(7), s.InputText, 126)) AS RoundedDatetime
FROM (VALUES
('2026-01-02T12:00:00.0010000'),
('2026-01-02T12:00:00.0020000'),
('2026-01-02T12:00:00.0050000'),
('2026-01-02T12:00:00.0080000'),
('2026-01-02T23:59:59.9990000')) AS s(InputText);SYSDATETIME Cannot Widen the Destination Type
Using SYSDATETIME does not improve a column declared datetime. Assignment converts its result to the target type. A datetime2(3) column also retains only its chosen scale, rather than the function's complete seven-place representation. Review defaults and column types together.
For new event storage, use a clear UTC contract and a datetime2 scale matching the application's needs. An offset-aware value can instead use datetimeoffset when retaining that offset matters. Do not mix local and UTC meanings in the same column without an explicit conversion policy.
The temporary example captures one UTC value, then stores that same instant in several types. This separates destination rounding from differences caused by taking several clock readings. Check the results before choosing a permanent schema or changing a legacy timestamp column.
DECLARE @CapturedUtc datetime2(7) = SYSUTCDATETIME();
CREATE TABLE #TimestampStorage
(
OldPrecision datetime NOT NULL,
MillisecondPrecision datetime2(3) NOT NULL,
FullPrecisionUtc datetime2(7) NOT NULL,
OffsetUtc datetimeoffset(7) NOT NULL
);
INSERT #TimestampStorage
VALUES (@CapturedUtc, @CapturedUtc, @CapturedUtc,
TODATETIMEOFFSET(@CapturedUtc, '+00:00'));
SELECT OldPrecision, MillisecondPrecision, FullPrecisionUtc, OffsetUtc
FROM #TimestampStorage;
UTC Removes Local Clock Ambiguity
Local wall-clock times repeat during the fall daylight-saving transition and skip during the spring transition. A local datetime2 value alone cannot identify which occurrence of a repeated time you meant. UTC gives stored event instants one shared reference frame.
Use UTC for event storage and convert for presentation using the required time-zone rule. A stored offset describes one instant's offset, but is not a replacement for a named zone's future rules. Keep business dates that are genuinely local dates separate from event instants.
I look for column names ending in Utc when checking timestamp contracts, then verify that their defaults actually use UTC. Names help communicate the rule but do not enforce it. A column named CreatedUtc with a GETDATE default on a local-time server remains local data with an optimistic label.
DECLARE @UtcInstant datetime2(7) = SYSUTCDATETIME();
SELECT @UtcInstant AS StoredUtc,
(@UtcInstant AT TIME ZONE 'UTC') AT TIME ZONE 'Eastern Standard Time'
AS EasternPresentation;Repeated SYSDATETIME Calls Can Share One Value
Seeing the same timestamp twice in one statement is expected behavior. SQL Server can evaluate current-time expressions as runtime constants within an execution context. A set-based SELECT therefore does not promise a fresh independent clock reading for every output row.
The two calls below can display the same value. That does not prove the clock stopped or the functions have only coarse precision. Expression evaluation and clock resolution both influence the observation. Do not build correctness around every separate syntactic occurrence being equal or different.
When one exact value must be reused, capture it in a variable. That gives the operation an explicit timestamp contract independent of expression evaluation details. If you need a later reading, take one at the appropriate later step rather than assuming a repeated SELECT expression acts as a stopwatch.
SELECT SYSDATETIME() AS FirstCall, SYSDATETIME() AS SecondCall;
DECLARE @OperationUtc datetime2(7) = SYSUTCDATETIME();
SELECT @OperationUtc AS HeaderUtc, @OperationUtc AS DetailUtc;A Clock Value Is Not a Unique Sequence
Several events can share a timestamp. Separate hosts can also have clock differences, and clock adjustments can affect ordering. A high-precision time function does not guarantee uniqueness or strictly increasing values across every operation.
Use a separate identifier or approved sequence when deterministic event ordering matters. Keep the timestamp for the event's clock meaning, and use a tie breaker when sorting. Do not make the timestamp the sole uniqueness key simply because seven decimal places appear unlikely to repeat.
Which requirement do you need, a clock instant or an exact ordering of writes? A sequence and a timestamp answer different questions. For elapsed-time performance measurements, use the appropriate measured execution statistics instead of subtracting loosely evaluated current-time expressions in a SELECT.
Choose the Function From the Data Contract
Keep GETDATE and CURRENT_TIMESTAMP where an existing datetime contract requires them. Use SYSDATETIME when local datetime2 precision is intended. Use SYSUTCDATETIME for an explicit UTC datetime2 contract, and SYSDATETIMEOFFSET when the offset belongs in the value.
Test round trips through application parameters, exports, and reporting formats. A precise database column can still lose information when the application converts it to a narrower type. Verify stored meaning as well as displayed digits, especially at midnight and daylight-saving boundaries.
The higher-precision function improves the available representation, not every surrounding assumption. Choose the time reference, destination type, and reuse policy together. Then the timestamp has a clear meaning that survives both storage and presentation.
Related reading on this blog: Convert Date Time AT TIME ZONE and Puzzle: Datatime to DateTime2 Conversation in SQL Server 2017.
Timestamp precision is not clock accuracy, it is the detail the chosen type can represent.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
