# Help me understand this clock based maths problem

I’m not a natural mathematician so perhaps the answer is really obvious to others however I would love to understand it.

It’s related to the number of times the hour hand and the minute hand cross over on a clock in a given day (i.e at midnight, at 1.05, 2.10 etc)

Many people might immediately assume the number of occasions is 24 but of course the minute hand is always creeping forward. The number of times the hour hand and minute hand meet in a day is 22. The hands come together once every 65 minutes and you can do the maths - 1440 (number of minutes per day) / 65 = 22

But it’s not 22 exactly. 1440 divided by 65 is 22.153846

However the clock effectively resets itself at the start of every day. So each day, as far as I can tell, always has 22 instances no more and no less.

Where does the 0.153846 disappear to?

After 65 minutes the minute hand will be on the 1 exactly, the hour hand will have passed the 1, it takes more than 65 minutes for them to line up.

Not sure where you got 65, but that is obviously incorrect, since if the hands are together at 12 o’clock for instance, 65 minutes later the minute hand is only on the 1 while it is past 1 o’clock.

ETA I see someone wrote the same thing. Anyway 24 hours divided by 22 is over 27 seconds longer than 65 minutes.

The mistake is here. Let’s say that you start at midnight, where both hands are aligned on 12. You are thinking that, 65 minutes later, both hands will be pointing at the 1am position but this is not the case. The minute hand will be pointing at the 1am position but the hour hand will be a little further away since it is not 1am but 1.05am. So the minute hand will need to rotate a little bit more to catch up with the hour hand.

If you want to do the math, both hands will cross at time t (in hours).
The hour hand rotates between two hour marks in 1 hour, so it will have rotated by t marks.
The minute hand between two hour marks in 1/12 hour, and it will have made an entire revolution (12 marks), plus t marks, at time t.

Solve:
t = (t+12)/12
t = t/12 + 12/12
11*t/12 = 12/12
t = 12/11 hours
t = 65.45454545 minutes

And 1440/65.45454545 = 22. Voilà!

:smack:

thanks all - I foolishly assumed the 65 minutes per cross over was exactly correct but I see now that it’s wrong!

But it is 22 exactly. It’s not exactly 65 minutes from one crossover point to the next. It’s more like 65 minutes and 27 seconds.

Numberphile actually has a video for it, though, unless I’m missing something, I think there’s a bit of an error at 2:33 where they show the overlap times, as they list them as 1:05.27, 2:10.55, 3:16.22 while they should be 1:05:27, 2:10:55, 3:16:22.

I think I see the gap in the problem. It’s a units problem!
1440 [minutes/day] / 65 minutes = 22.15… overlaps per day

.1538…*65 = 10 minutes and those 10 minutes are critical here because

00:00, 1:05 2:10 3:15 4:20 5:25 6:30 7:35 8:40 9:45 10:50 11:55
and then
12:00, 1:05 2:10 3:15 4:20 5:25 6:30 7:35 8:40 9:45 10:50 11:55

Do you notice something? 11:55-12:00 and 11:55-00:00 aren’t included 5 minutes + 5 minutes = 10 minutes!!! and that is where your 0.1538 comes from.

Edit: Or what pulykamell said, however, I bet you will add up to five minutes * 2 if you sum up 27 sec + 55 sec + 1min22sec + …

The 0.153846 is when the bellhop takes his break.

CMC fnord!

Not really units causing the problem, but units inspire the problem … … its the maths rounded off too severely.

it all depends on how time he was willing to assume was just rounding error. Which isn’t really a question of units, but the choice to use the units of time lead to the difficult spotting the rouding off.
With 22 events, if its rounded off to the minute, the error could be as large as 22 minutes. Work off the maximum, because that is because its not a random process at work. The synchronicity (nonrandomness) of the error might conspire to make the 22 errors all the largest possible errors, not a random collection of errors.

If rounded off to 100ths of a minute (100 because thats two digits in decimal) the error could be 22 of them wrong, which is approx 20 seconds.