ClockOrbit

Scientific time tool

Decimal day converter

Convert clock time to the fraction of a day elapsed since midnight, or convert the fraction back to HH:MM:SS. For example, 14:39:36 is about 0.610833.

Time to decimal day

0.5771759259

Fraction of one civil day elapsed since midnight.

Decimal day to time

13:51:08

Values outside 0 to 1 are clamped to the nearest day boundary.

00:00:000
06:00:000.25
12:00:000.5
18:00:000.75
23:59:590.99999

Quick conversion table

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 timeFraction of day
01:00:000.041667
03:00:000.125
06:00:000.25
08:00:000.333333
09:30:000.395833
12:00:000.5
15:00:000.625
18:00:000.75
20:00:000.833333
22:30:000.9375
23:59:590.999988

Converting 14:39:36 by hand

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.

Rounding, clamping, and the edges of a day

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.

Why decimal day fractions are useful

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.

Day fraction questions

Is a decimal day the same as decimal hours?

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.

How many decimal places do I need?

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.

Does the day fraction depend on the time zone?

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.

Why does entering 1 come back as 23:59:59?

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.

What about 24:00:00 or leap seconds?

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.