Scientific time tool
Convert a clock time into the fraction of a day elapsed since midnight, then convert a decimal day back into HH:MM:SS.
0.4691203704
Fraction of one civil day elapsed since midnight.
11:15:32
Values outside 0 to 1 are clamped to the nearest day boundary.
These anchor points cover the values people look up most. One hour is 1/24 of a day, about 0.041667; one minute is 1/1,440, about 0.000694; and one second is 1/86,400, about 0.0000116.
| Clock time | Fraction of day |
|---|---|
01:00:00 | 0.041667 |
03:00:00 | 0.125 |
06:00:00 | 0.25 |
08:00:00 | 0.333333 |
09:30:00 | 0.395833 |
12:00:00 | 0.5 |
15:00:00 | 0.625 |
18:00:00 | 0.75 |
20:00:00 | 0.833333 |
22:30:00 | 0.9375 |
23:59:59 | 0.999988 |
Count the seconds since midnight first: 14 hours are 50,400 seconds, 39 minutes add 2,340, and the final 36 brings the total to 52,776. Divide by 86,400 and the fraction is 0.610833. Going the other way, multiply 0.610833 by 86,400 to get 52,775.97, round to the nearest whole second, 52,776, and unpack it back into 14:39:36. Every conversion in either direction is just those two steps.
The reverse conversion rounds to the nearest whole second, so tiny input noise below half a second disappears rather than producing odd times. Fractions below 0 or above 1 are clamped to the day boundaries, and an input of exactly 1 resolves to 23:59:59 because the fraction scale runs from 0 up to, but never including, the next midnight. If you need sub-second fidelity, keep the raw fraction: each extra decimal place is worth a factor of ten, and the sixth place already resolves 0.0864 seconds.
Astronomers use Julian Day numbers to put observations on one continuous timeline. The integer identifies the day and the fractional part records the time within that day, so noon is 0.5, 18:00 is 0.75, and values near 1.0 are just before the next midnight. Scientists and statisticians use the same idea when a daily cycle is easier to model as a number from 0 to 1 than as separate hour, minute, and second fields.
In JavaScript, the arithmetic is the same: Date.now() / 86400000 expresses Unix time in days, and the fractional remainder is the elapsed fraction of the current UTC day. This tool uses local clock input instead, but the denominator is still 86,400 seconds per day.
Decimal time also has a civil-history branch. The French Republican calendar tried a decimal clock with ten hours per day, one hundred minutes per hour, and one hundred seconds per minute. It was rational and short-lived; ordinary 24-hour clocks won, while decimal fractions stayed useful in computation.
Spreadsheets quietly use the same representation: a cell holding a time of day stores it as a day fraction, so 0.75 formats as 18:00 and adding 0.25 to a timestamp advances it by six hours. Astronomers who work with Modified Julian Dates get the same convenience, since the MJD day begins at midnight and its fractional part matches the value this converter produces directly.
No. Decimal hours, common in payroll and billing, express minutes as a fraction of one hour, so 7:30 becomes 7.5 hours. A decimal day divides the whole clock reading by 86,400 seconds, so 7:30 in the morning becomes 0.3125 of a day.
One part in a million of a day is 0.0864 seconds, so six decimal places distinguish every individual second comfortably. Five places resolve about 0.86 seconds, which is enough when the source data is only minute-accurate anyway.
The fraction encodes a wall-clock reading, nothing more. Two people at the same instant in different zones get different fractions because their clocks read differently, but the arithmetic in both directions is identical everywhere.
A day fraction lives in the interval from 0 up to, but not including, 1, because the next midnight belongs to the following day. The converter clamps out-of-range input and caps the result at the last second, 23:59:59.
The converter treats every civil day as exactly 86,400 seconds, the same convention Unix time uses. Leap seconds are ignored, and 24:00:00 is not a valid input since that instant is 0.0 of the next day.