Ticks Converter. C# .NET DateTime Ticks to Date

What a tick is

A DateTime.Ticks value counts 100-nanosecond intervals since midnight on January 1, year 1 (0001-01-01). It is the internal representation of every System.DateTime and DateTimeOffset, and the reason EF Core rowversions and Stopwatch readings look like huge 18-digit numbers:

• DateTime.UtcNow.Ticks, current time in ticks.
• DateTimeOffset.UtcNow.Ticks, same count, no offset applied.
• Stopwatch.GetTimestamp(), a similar 100ns count on Windows.
• File LastWriteTimeUtc.Ticks, stored timestamps in .NET code.

The gap between year 1 and the Unix epoch (1970) is 621355968000000000 ticks — exactly 62135596800000 ms.

The tick-to-Unix conversion, one division each way

• Ticks → Unix ms: ticks / 10_000 - 62135596800000.
• Unix ms → Ticks: (ms + 62135596800000) * 10_000.

Tick counts, decoded

• 621355968000000000 → January 1, 1970 00:00:00 UTC, the Unix epoch, in ticks.
• 639216576000000000 → August 7, 2026 00:00:00 UTC.
• Maximum: 3155378975999999999 → December 31, 9999 23:59:59.9999999.

Ticks in C#, PowerShell, and Python

• C#: new DateTime(639216576000000000, DateTimeKind.Utc) and DateTime.UtcNow.Ticks.
• PowerShell: [DateTime]::new(639216576000000000, [DateTimeKind]::Utc).
• Python: datetime(1, 1, 1, tzinfo=timezone.utc) + timedelta(microseconds=ticks / 10).
• Go: time.Unix(0, (ticks-621355968000000000)*100).

Gotchas: precision, the year-1 epoch, and Kind

• Precision loss, current tick counts (~18 digits) exceed JavaScript's safe-integer range; this converter reads and writes them with BigInt.
• Not a Unix value, ticks count from year 1, so an unadjusted paste lands in year 1, not 1970. Apply the 621355968000000000 offset.
• Kind matters. DateTime ticks are the same count regardless of Kind; only the interpretation (Local vs UTC vs Unspecified) changes.
• Range.NET supports year 1 through 9999. Dates outside that range simply don't exist as ticks.