I'm afraid there is nothing I, for one, can do with anything MAX. :7
The test clock was actually with a second and a minute hand, rather than a minute and hour one (because I'm an impatient sod), so the fat hand should actually rotate one 60th of a turn, per full rotation of the thin one, and take one hour in total... It did perfectly on my end, checking with a stopwatch and running on the POTS build of Plasma. Maybe if you are running in on MOUL, your results may vary, on account of the previously mentioned 16bit limitation...
There are probably a whole host of ways in which you could rig a full day solution up, while working with the limitations.
Going Python altogether may be the easiest solution in many ways; Letting the script keep the time and "forcibly" taking care of rotation, foregoing keyframe animation.
You could also make the hands move in discrete jumps, every minute/hour, rather than slowly crawl, which would not require the looong curves.
Another idea, if one want both to do it with animation and have the crawl, could be to parent the hands, maybe with an empty object or two, as intermediaries, to overcome the timeline length limitation. Set an animation marker that calls back after half an hour and have the event, that waits for that callback, restart the minute hand's half-rotation animation, as well as increment the two frame rotation animation of the hand's parent (should together result in a full hour rotation, hopefully without any annoying spats every full- and half hour). (EDIT: Same thing for the hour hand, but with a 24 frame parent - could use the same callback as the minute hand.)
Just some half-baked thoughts...