Convert an ISO datetime to Windows FILETIME
Enter a date and time with Z or an offset and get the Windows FILETIME count of 100-nanosecond steps since 1 January 1601 UTC: 2025-01-01T00:00:00Z is 133801632000000000. Handy for Active Directory, registry data and forensics. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Datetime
- 2025-01-01T00:00:00Z
- Input datetime
- 2025-01-01T00:00:00Z
- Utc datetime
- 2025-01-01T00:00:00.0000000Z
- Windows filetime
- 133801632000000000
Convert an ISO 8601 datetime into the decimal Windows FILETIME value used by Windows APIs, Active Directory, registry data, and many forensic tools. The calculation counts 100-nanosecond intervals from 1601-01-01T00:00:00Z and requires the input to state its timezone explicitly, either with Z or a numeric offset. It uses exact integer and Gregorian calendar arithmetic rather than the local clock or a platform date parser. The response includes the original input, its normalized UTC representation with seven fractional digits, the FILETIME decimal string, and a clear unit label for reliable inspection or automation.
Understand the Windows FILETIME epoch and unit
Windows FILETIME is an integer count whose zero point is midnight UTC on January 1, 1601. Each increment represents 100 nanoseconds, so ten million units equal one second and 864 billion equal one day. This epoch and resolution differ from Unix time, JavaScript milliseconds, and .
NET DateTime ticks, which means simply changing a label or multiplying a familiar timestamp can produce the wrong result. The converter first validates the supplied Gregorian date, clock time, fractional second, and timezone. It then determines the exact UTC instant and measures the interval from the FILETIME epoch with integer arithmetic.
Keeping the result as text prevents silent rounding in browsers, spreadsheets, and application runtimes.
Use explicit ISO timezones for deterministic UTC conversion
An ISO date and clock time without a timezone does not identify one instant. It could mean a workstation's local time, a server timezone, or a value whose offset was lost during export. This capability therefore requires either Z for UTC or a numeric offset such as +05:30 or -04:00.
A positive offset is subtracted to reach UTC, while a negative offset is added. For example, midnight at +02:00 corresponds to 22:00 UTC on the previous calendar day. The calculation handles that day boundary directly and returns the normalized result with a trailing Z.
It never consults the machine timezone, daylight-saving database, current date, locale, or environment settings, so identical text produces identical output everywhere. Numeric offsets are accepted up to 14:00, matching the practical range of civil timezones. Named zones such as America/New_York are intentionally unsupported because resolving them requires historical rule data that can change.
If a source only contains a local datetime, determine and append the correct offset at that historical moment before converting; guessing an offset here would turn an ambiguous record into a confidently wrong FILETIME.
Preserve precision and validate migration data
The input may contain from one through seven fractional-second digits. Missing digits are padded on the right, so .1 means one tenth of a second, while seven digits express the full 100-nanosecond resolution of FILETIME. More than seven digits are rejected instead of rounded or truncated because either choice could silently move the represented instant.
Calendar validation also rejects impossible dates, leap seconds, malformed offsets, and clock values outside their normal ranges. After timezone conversion, the UTC instant must fall between the FILETIME epoch and the final 100-nanosecond interval of year 9999. These strict boundaries make the converter useful in migration validation: bad source rows fail visibly rather than wrapping into a large integer.
What you can do with it
Validate directory migrations
Calculate FILETIME values for timestamp fields while retaining a normalized UTC value that reviewers can audit.
Analyze registry and forensic timelines
Create known FILETIME reference values from explicit ISO instants for tests, investigations, and timeline tooling.
FAQ
What is the Windows FILETIME epoch?
FILETIME begins at 1601-01-01T00:00:00Z and counts 100-nanosecond intervals from that instant.
Why must the ISO datetime include a timezone?
A date and time without Z or an offset is ambiguous. Requiring a timezone makes conversion to UTC deterministic.
How many fractional digits are accepted?
Up to seven digits are accepted, matching FILETIME's 100-nanosecond resolution. Greater precision is rejected rather than rounded.
Does the converter use the system timezone or clock?
No. It uses only the explicit input and deterministic Gregorian integer arithmetic.
Why is the result shown as text rather than a number?
Because modern FILETIME values are bigger than many programs and spreadsheets can hold exactly as numbers. Keeping the value as text avoids silent rounding before you store it or pass it on.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/date/iso-to-windows-filetime \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"datetime":"2025-01-01T00:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/date/iso-to-windows-filetime", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"datetime": "2025-01-01T00:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/iso-to-windows-filetime",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"datetime": "2025-01-01T00:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/iso-to-windows-filetime", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"datetime":"2025-01-01T00:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"datetime":"2025-01-01T00:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/iso-to-windows-filetime", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"datetime": "2025-01-01T00:00:00Z"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.iso_to_windows_filetime",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Understand the Windows FILETIME epoch and unit
The returned windows_filetime field is decimal text because modern FILETIME values exceed the range that many JSON number implementations can represent exactly. The unit field documents the interpretation beside the value, while utc_datetime gives a readable representation that can be checked before the integer is stored or passed to another system. Automated conversions cost $0.002 per item.
Preserve precision and validate migration data
Use windows_filetime when writing a Windows structure, LDAP attribute, registry export, or compatibility payload.
Integration use cases
Prepare Windows API payloads
Convert a human-readable UTC or offset datetime into the exact decimal FILETIME expected by a Windows integration.
Technical questions
Why is the FILETIME returned as a string?
Typical FILETIME integers exceed the exact range of common JSON numbers. Decimal text preserves every digit.
What does one conversion cost?
Each API conversion costs $0.002.