.NET Ticks Converter

Convert between a .NET DateTime.Ticks value and an ISO 8601 date. Useful when a database column, log file, or serialized object contains raw tick values. Everything runs in your browser.

What a tick is

A .NET tick is 100 nanoseconds, so there are 10 million ticks in one second. DateTime.Ticks counts them from 0001-01-01T00:00:00, which is DateTime.MinValue.

Two things make tick values look unfamiliar compared to Unix timestamps: the much finer unit and the much earlier origin. Both push the numbers into 18-digit territory.

IntervalTicks
1 microsecond10
1 millisecond10,000
1 second10,000,000
1 minute600,000,000
1 hour36,000,000,000
1 day864,000,000,000

The Unix epoch offset

Converting between ticks and Unix time requires one constant:

621355968000000000

That is the tick value of 1970-01-01T00:00:00Z, the number of 100-nanosecond intervals in the 1969 years between year 1 and the Unix epoch. With it, conversion is arithmetic:

Note that these values exceed JavaScript's safe integer range of 253. This tool uses BigInt arithmetic so no precision is lost, which matters because an ordinary double would silently round the low-order digits.

Examples

TicksDate (UTC)Note
00001-01-01T00:00:00ZDateTime.MinValue
6213559680000000001970-01-01T00:00:00ZThe Unix epoch
31553789759999999999999-12-31T23:59:59ZDateTime.MaxValue

Practical notes

Resolution versus accuracy

A tick represents 100 nanoseconds, but that does not mean DateTime.Now is accurate to 100 nanoseconds. On Windows the system clock typically updates every 10 to 15 milliseconds, so consecutive calls often return identical values with many trailing zeros. For measuring elapsed time, use Stopwatch, which draws on a high-resolution performance counter instead.

Millisecond truncation when converting

A JavaScript Date holds only millisecond resolution, so converting ticks to a date here truncates anything finer. A tick value ending in non-zero sub-millisecond digits will not round-trip back to exactly the same number. If exact ticks matter, keep the original value.

DateTime versus DateTimeOffset

DateTime carries a Kind property that is Utc, Local, or Unspecified. The Ticks value itself does not encode which, so a bare tick number is ambiguous about its zone. DateTimeOffset stores an explicit offset alongside the value and is generally the safer choice for anything crossing time zones or persisting to storage.

TimeSpan uses the same unit

TimeSpan.Ticks counts the same 100-nanosecond intervals but measures a duration rather than a point in time. A TimeSpan of 1 second is 10,000,000 ticks, with no epoch offset involved.

Frequently asked questions

Why is the number so much larger than a Unix timestamp?

Two reasons: ticks are 100-nanosecond units rather than seconds, a factor of 10 million, and they count from year 1 rather than 1970, adding another 621 quadrillion.

What is the maximum supported value?

DateTime.MaxValue, which is 9999-12-31 23:59:59.9999999 or 3,155,378,975,999,999,999 ticks. Larger values are rejected with a clear error.

How do I convert ticks to a Unix timestamp?

Subtract 621355968000000000 and divide by 10,000,000. The result is Unix seconds.

Are ticks in UTC or local time?

The tick value alone does not say. It depends on the Kind of the DateTime it came from. This tool treats input as UTC. Use DateTimeOffset in your code to avoid the ambiguity.

Why do my tick values end in many zeros?

Because the system clock updates roughly every 10 to 15 milliseconds on Windows, not every 100 nanoseconds. The resolution of the type exceeds the precision of the clock.

Do other platforms use ticks?

The 100-nanosecond unit also appears in Windows FILETIME, though that counts from 1601 rather than year 1. Most non-Windows platforms use Unix timestamps in seconds or milliseconds.

Related tools