A tick is 100 nanoseconds, or one ten-millionth of a second. A .NET DateTime stores the number of ticks elapsed since midnight on 1 January in the year 1, in the proleptic Gregorian calendar.

How do ticks relate to Unix time?

The Unix epoch of 1 January 1970 corresponds to 621,355,968,000,000,000 ticks. The tool subtracts that offset to map a tick count onto a normal date and adds it back when converting the other way.

Why does the tool use BigInt?

Tick counts can exceed the safe integer range of a JavaScript number. Using BigInt keeps the arithmetic exact across the whole 64-bit range, so no precision is lost in the high-order digits.

Can it show fractions of a second?

Yes. If the tick count has a sub-second component, the result shows the full seven-digit 100-nanosecond fraction rather than rounding to milliseconds.

What is the maximum tick value?

DateTime.MaxValue is the last tick of 31 December 9999, which is 3,155,378,975,999,999,999 ticks. The tool rejects values above this as out of range.

What is the .NET DateTime Ticks Converter?

Convert a .NET DateTime tick count to a UTC date and back. One tick is 100 nanoseconds counted from 0001-01-01, and the tool uses exact BigInt arithmetic so the full 64-bit range and sub-second precision are preserved. It runs free in your browser on Gera Tools, with nothing uploaded.

.NET DateTime Ticks Converter

Name: .NET DateTime Ticks Converter
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

What .NET ticks are

In .NET a DateTime is stored as a single number called ticks. One tick is 100 nanoseconds, and the count starts at midnight on 1 January of the year 1. That fine resolution and distant origin make raw tick values hard to read, so this tool converts them to ordinary UTC dates and back, keeping full precision the whole way.

How it works

The key constant is the tick value of the Unix epoch. Midnight on 1 January 1970 is 621,355,968,000,000,000 ticks. To turn a tick count into a date the tool subtracts that offset, divides by 10,000 to reach milliseconds for a standard date object, and then re-attaches the leftover 100-nanosecond fraction so nothing is lost. The reverse direction multiplies the date’s milliseconds by 10,000 and adds the epoch offset back.

All of this is done with BigInt, because a 64-bit tick count is far larger than the range a JavaScript number can hold exactly.

Conversion reference

Ticks	UTC date
0	0001-01-01T00:00:00Z (DateTime.MinValue)
621,355,968,000,000,000	1970-01-01T00:00:00Z (Unix epoch)
637,985,656,000,000,000	2022-09-12T07:46:40Z
638,000,000,000,000,000	2022-09-28T22:13:20Z
3,155,378,975,999,999,999	9999-12-31T23:59:59.9999999Z (DateTime.MaxValue)

Where .NET ticks appear in practice

.NET serialization. Libraries like Newtonsoft.Json and System.Text.Json can serialize DateTime as ticks in binary formats. When reading raw log files or binary database columns, you may see long integers in the 63x–64x quadrillion range that are tick values.

Windows FILETIME vs .NET ticks. Windows FILETIME is a similar concept but uses a different epoch: it counts 100-nanosecond intervals since 1 January 1601 rather than 0001-01-01. The offset between the two is 504,911,232,000,000,000 ticks (the number of 100-ns intervals between 0001-01-01 and 1601-01-01). Do not use this tool for FILETIME values — use a dedicated FILETIME converter.

Database columns. Some .NET ORM configurations store DateTime as ticks in a bigint column for precision or performance. If you see a bigint in a SQL Server or SQLite database containing a value in the 630–640 quadrillion range, it is likely a UTC tick value for a date in the 2010s to 2020s.

The BigInt precision issue

JavaScript’s Number type is a 64-bit IEEE 754 double, which has only 53 bits of integer mantissa. A tick value like 638,000,000,000,000,000 has 18 significant decimal digits and requires more than 53 bits to represent exactly — so standard JavaScript arithmetic loses precision in the lower digits. This tool uses BigInt throughout to keep all 18–19 digits exact, which matters when you need sub-millisecond accuracy (each millisecond is 10,000 ticks).

Example and notes

Tick values you encounter in logs and serialized objects are almost always in UTC, which is how this tool interprets and emits them. If you have a local time instead, convert it to UTC before entering it, otherwise the result will be off by your timezone offset. The maximum supported value is the final tick of the year 9999, matching DateTime.MaxValue; larger inputs are rejected as out of range.