.NET DateTime Ticks

.NET DateTime ticks count 100-nanosecond units since 00:00:00 on 1 January of year 1 in the proleptic Gregorian calendar. Paste a tick integer to see UTC, or pick a calendar date to encode midnight UTC as ticks. The Unix epoch is the well-known tick value 621355968000000000. This scale is not POSIX seconds, not Windows FILETIME, not Cocoa/NSDate, and not WebKit microseconds. Mixing those integers in a C# log parser is a standard outage report.

What a tick is

One tick equals 100 nanoseconds, so 10,000 ticks equal one millisecond and 10,000,000 ticks equal one second. DateTime.Ticks is a 64-bit count from year 1, not from 1970. DateTimeOffset and DateTime both expose Ticks; DateTimeKind (Utc, Local, Unspecified) is extra metadata that does not change how many ticks have elapsed since year 1 for a given UTC instant, but Local kind can confuse readers who assume the printed clock is UTC.

TimeSpan.Ticks uses the same 100-nanosecond unit but measures a duration, not an absolute instant. A TimeSpan of one hour is 36,000,000,000 ticks and must not be pasted into this converter as if it were a DateTime. If the integer is smaller than about 6.2e17, it may be a span, a Unix millisecond, or FILETIME rather than a DateTime tick from year 1.

Leap seconds are not represented. .NET DateTime follows the same 86400-second civil day model as most business software. SQL Server datetime2 also uses 100-nanosecond-ish precision depending on scale, but the epoch and packing are not DateTime.Ticks; do not paste a SQL binary datetime into this box.

Other 100-nanosecond clocks are not this one

Windows FILETIME counts 100-nanosecond units from 1 January 1601 UTC. Convert FILETIME on the FILETIME converter. The offset between year 1 and 1601 is a fixed tick gap; feeding FILETIME into DateTime.Ticks math without that gap yields dates in the sixteenth century or throws. LDAP/Active Directory timestamps are FILETIME values, not .NET DateTime ticks.

Unix seconds count from 1970. Multiply Unix seconds by 10,000,000 and add 621355968000000000 to reach DateTime ticks for that UTC second. This page performs that mapping when you pick a date (midnight) or when you paste ticks and it prints Unix seconds as a convenience line. Do not treat the Unix line as the native .NET storage format.

Cocoa/NSDate counts seconds from an epoch thirty-one years after Unix. WebKit timestamps often use microseconds from 1601, in the FILETIME family. GPS and NTP have still other epochs (1980 and 1900). If a ticket says “ticks” without “.NET DateTime,” ask which epoch before pasting.

How to convert on this page

Digits-only input is treated as ticks. The engine subtracts the Unix-epoch tick constant, scales to milliseconds, and builds a UTC Date. Out-of-range values that JavaScript cannot represent are rejected. Date input without ticks encodes 00:00:00 UTC on that day and prints a C# hint of the form new DateTime(ticks, DateTimeKind.Utc).

Kind.Utc in that hint is a reminder: store UTC in logs. Kind.Local plus a server moved between zones rewrites history. Kind.Unspecified is how many serializers leak ambiguity. The integer ticks still mean “since year 1,” but the civil clock you print must name the kind.

JSON serializers differ. Some emit ISO-8601 strings. Others emit ticks as an integer or as /Date(milliseconds)/ leftovers from old ASP.NET. If you see a 13-digit number, it is probably Unix milliseconds, not ticks. Ticks for modern dates are 18 digits starting with 63.

Worked tick examples

Encode 1 January 2026 00:00 UTC. Copy the tick integer into a unit test that asserts round-trip DateTime. Specify DateTimeKind.Utc in the test. Decode the same integer here and confirm the ISO line matches the date you picked.

Paste 621355968000000000. The UTC line should be the Unix epoch (1 January 1970). If you see a local clock that is not 00:00, you are printing Local kind in your head; the instant is still Unix epoch. That constant is a useful fixture in mixed Java/.NET shops.

A log shows 638 followed by 15 more digits. Decode here. If the civil date matches the incident, the field is DateTime ticks. If the date is nonsense, try Unix seconds, Unix milliseconds, or FILETIME next. Keep the Unix timestamp and FILETIME pages in the same bookmark folder as this one.

SQL, BSON, and interop

SQL Server datetime2(7) can store 100-nanosecond precision but conversion functions do not equal DateTime.Ticks. NodaTime Instant uses a different epoch internally (Unix nanoseconds or similar). MongoDB Date is Unix milliseconds in BSON. When a .NET app writes ticks into a varchar “because it is precise,” partner teams in Python will hate you; prefer ISO-8601 UTC in text APIs.

Excel serial dates are days from 1899/1900 with a leap-year bug. They are not ticks. Spreadsheet round-trips should go through civil dates, not through 18-digit integers that Excel will display in scientific notation and round.

Browser JavaScript Number cannot integer-exact every tick above 2^53. This page uses BigInt for the tick math so 18-digit values survive. Copy-paste from a language that stringifies ticks as floats will already have lost low bits before you arrive.

Related tools

POSIX seconds: Unix timestamp. 1601 100-ns clock: FILETIME converter. Other encodings: converters hub.