Time is the one quantity where unit errors are both easiest to make and hardest to spot, because the conversion factors are irregular — 60, 60, 24, 7, then 30.44 — and the useful range spans twenty orders of magnitude. A converter removes the arithmetic; knowing which convention you are converting under is the part that still needs judgement.

Why the Factors Are Not Powers of Ten

Below the second, time is metric: milliseconds, microseconds, and nanoseconds each step down by a factor of 1,000, exactly like millimetres and metres. Above the second, it is not. Sixty seconds to the minute and sixty minutes to the hour are inherited from Babylonian base-60 arithmetic, twenty-four hours from Egyptian day division, and seven days from the week's astrological origins. None of it was designed to be divided.

The practical consequence is that mental conversion works reliably in one direction only. Most people can turn 3 hours into 180 minutes; far fewer can turn 47,000 seconds into hours and minutes without slipping. Anything crossing more than two unit boundaries — seconds to days, milliseconds to hours — is where errors concentrate.

Calendar Time vs Working Time

This is the distinction that costs money. A task estimated at 80 hours is two working weeks or three and a third calendar days, and those two answers lead to completely different commitments. Convert with the wrong one and you have either promised a fortnight of work by Thursday or padded a three-day job into a fortnight.

The business-hours filter exists for exactly this. With it on, a day is 8 hours and a week is 40, so hour counts map onto the schedule people actually work. Leave it off for anything measuring real elapsed time — server uptime, cure times, incubation periods, shipping transit — where nights and weekends pass whether anyone is working or not.

Where Months and Years Get Fuzzy

Seconds through weeks are exact. Months and years are not, because a month is 28 to 31 days and a year is 365 or 366. Any converter has to pick an average, and this one uses the Julian convention: 365.25 days per year, 30.4375 days per month.

That is the right default for spans of a year or more, where the averaging washes out. It is the wrong tool for a specific month. "90 days from 15 January" is not "3 months from 15 January" — the first lands on 15 April in a common year, the second on 15 April too, but start in December and the two answers diverge. For contractual or billing dates tied to real calendar boundaries, count the actual days.

Reading Across the Whole Range at Once

The comparison table below the result shows your value in every supported unit simultaneously, which is more useful than it first appears. Seeing that a 30-day sprint is also 720 hours, 2.59 million seconds, and 0.082 years gives you an immediate sense of scale — and it catches order-of-magnitude mistakes instantly, because a wrong input produces a row that is obviously absurd.

It is also the fastest way to sanity-check a figure someone else produced. If a report claims a process takes 500,000 seconds, the table tells you that is 5.8 days, not the couple of hours the author may have assumed.