How to use the filetime and .net ticks converter
- Choose the kind of value you have, such as Windows FILETIME, .NET ticks, Unix seconds or an ISO date and time.
- Type or paste the value. Whole numbers keep every digit, and a decimal part is allowed for the formats that use one.
- Read the UTC date and time and the weekday at the top, then the same moment in every other format in the table.
- Copy the line you need, or download the table as a CSV file.
Formula
ticks since 0001-01-01 = start of format in ticks + value x ticks per unit
FILETIME = ticks - 504,911,232,000,000,000
Unix seconds = (ticks - 621,355,968,000,000,000) / 10,000,000
Excel serial = (ticks - 599,264,352,000,000,000) / 864,000,000,000
A tick is 100 nanoseconds, so 10 million ticks make a second. All formats are shifted copies of one count of ticks, which is why they convert exactly. Julian day numbers start at noon, so a date at midnight ends in .5.
A FILETIME from February 2024
The FILETIME 133536834450000000 is 133,536,834,450,000,000 ticks after 1601-01-01. Adding the 504,911,232,000,000,000 ticks between 0001 and 1601 gives 638,448,066,450,000,000 .NET ticks, and subtracting the 621,355,968,000,000,000 ticks to the Unix epoch leaves 17,092,098,450,000,000 ticks, which is 1,709,209,845 seconds.
That moment is Thursday 2024-02-29T12:30:45Z. As an Excel serial date it is 45351.52135417, as Unix milliseconds 1709209845000 and as a Julian day 2460370.02135417.
Where each format shows up
FILETIME is used by Windows file systems and many Microsoft protocols. .NET ticks are the DateTime value in C# and related languages. WebKit time, used by Chrome for cookies and history, counts microseconds from 1601, and Mac absolute time counts seconds from 2001. Excel counts days from the end of 1899, and astronomers count Julian days.
To work with ordinary Unix timestamps in your own time zone, use the Unix Timestamp Converter. To read the time hidden inside ids, use the ID Timestamp Decoder.
Limits worth knowing
Dates run from year 1 to year 9999 and are always UTC in the proleptic Gregorian calendar, which extends today's rules backwards before 1582. Excel serial numbers are only shown from 1900-03-01 because Excel counts 29 February 1900, a day that never existed.
A value finer than 100 nanoseconds is rounded to the nearest tick, halves going up. Days written as decimals are rounded to 8 places.
Assumptions and limits
- Every date is in Coordinated Universal Time. No time zone or daylight saving rule is applied.
- Years 1 to 9999 are accepted; anything outside is rejected with a message.
- Excel serial numbers below 61 are not converted because of the 1900 leap year quirk.
- The Julian day number is the continuous day count, with the day starting at noon, not the "Julian date" of day of year in a different calendar.
- An ISO date and time needs a four digit year, a full date, and may have up to 7 decimals in the seconds.
Frequently asked questions
Why is a Windows FILETIME so large?
It counts 100 nanosecond steps since 1601. Ten million steps make a second, so a date in 2024 is about 1.3 x 10^17 steps. The page uses whole number arithmetic so none of those digits are lost.
What is the difference between .NET ticks and FILETIME?
Both count 100 nanosecond steps, but .NET ticks start at 0001-01-01 and FILETIME starts at 1601-01-01. The two always differ by 504,911,232,000,000,000.
Why is there no Excel value for early dates?
Excel treats 1900 as a leap year, which shifts every date before March 1900 by a day compared with the real calendar. Showing a number there would be misleading.
Does the page use my time zone?
No. Everything is in UTC, so the same input gives the same answer on every computer.