Convert a value from one time unit to another — milliseconds, seconds, minutes, hours, days, weeks, months, years, or decades. Both inputs are editable, so you can type into either side and the other recomputes. Useful for API payloads that want durations in one unit when you have them in another, for sanity-checking back-of-envelope estimates, and for answering the “how many X in a Y” questions that come up constantly in engineering and project planning.
Exact vs approximate units
The tool splits its units into two groups, and the distinction matters.
Exact units — milliseconds, seconds, minutes, hours, days, and weeks — are all fixed integer multiples of each other. A minute is exactly 60 seconds. An hour is exactly 60 minutes. A day is exactly 24 hours. A week is exactly 7 days. Convert among these and you get clean, exact answers with no rounding surprises.
Approximate units — months, years, and decades — are not. Real months have 28 to 31 days. Real years have 365 or 366 days. The tool uses the Gregorian mean year (365.2425 days) as a canonical value, which is the right long-run average over a 400-year leap cycle. A month is defined as year / 12 = 30.4369 days. Those give you answers like “1 year ≈ 52.18 weeks” that are accurate on average but don’t correspond to any single specific calendar interval.
When your conversion touches an approximate unit, the tool shows a warning note below the result card explaining that the answer uses the Gregorian mean year rather than a specific calendar duration. For exact conversions — seconds to hours, days to weeks, milliseconds to minutes — the warning doesn’t show because there’s nothing to qualify.
Example: 7 weeks to seconds
A common back-of-envelope question: “This background job runs for 7 weeks; how many seconds is that for the rate limiter budget?” Type 7 in the source, set the unit to Weeks, set the target to Seconds. Answer: 4,233,600 seconds. That’s the default value the tool loads with, since it’s the canonical illustration of an exact conversion.
The math: 7 × 7 × 24 × 60 × 60 = 4,233,600. Week → day → hour → minute → second, all exact integer multiples.
Example: one month in hours (approximately)
You’re estimating server costs for a monthly job. “How many hours is a month, roughly?” Pick Months on the source, Hours on the target, type 1. Answer: 730.485 hours. Round to 730 for back-of-envelope work, or to 720 if you want the “30-day month” approximation most infrastructure pricing uses.
The warning note will show up — because the answer uses 30.4369 days per month, which is correct on average across the Gregorian calendar but doesn’t match any specific month. February will give you fewer hours, a 31-day month will give you more. The tool’s answer is the mean over a long time horizon.
Example: milliseconds to seconds for timestamps
JavaScript’s Date.now() returns milliseconds since the Unix epoch, but most other languages and most databases store seconds. If you have a timestamp like 1776263696000 and want to know what it is in seconds, divide by 1000 — or just paste it into this tool with ms on the source and sec on the target. The same direction is useful in reverse: if you’re setting a cache TTL in milliseconds but your config thinks in seconds, the tool saves you from having to type the zero count manually.
Quick picks
The pills above the inputs jump you directly to common unit pairs:
- weeks ↔ sec — the 7-weeks-to-seconds reference pair
- days ↔ hours — for sprint planning and shift math
- hours ↔ min — for scheduling and time-tracking
- years ↔ days — approximate, for rough duration estimates
- ms ↔ sec — for timestamp and timing work
Clicking a pill sets both dropdowns without touching the value, so you can compare “how long is this in various units” without retyping.
What this tool does not do
It doesn’t parse human strings like “1h 30m” or “2 days 4 hours”. If you need that, you probably want a dedicated duration parser or a library like pretty-ms / parse-duration. This tool is strictly number-in, number-out.
It doesn’t account for leap seconds. Practical time conversion ignores them — UTC itself smears them across the day on most systems, and no common rate-limiter, cache TTL, or timestamp arithmetic needs them. If you’re writing high-precision astronomy code, you need a different tool.
It doesn’t convert to calendar dates. “What’s 5 million seconds from now” is a date arithmetic question, not a unit conversion — use the date difference calculator or the ISO 8601 parser for that.
It doesn’t format results as composite strings like “2 weeks, 3 days, 4 hours.” That’s a display question, not a conversion — it needs a duration formatter. This tool gives you a single scalar number in the target unit.