- Noon = 5999.5 (as expected, within that half tick)
- Next frame should be 375 (24000/64) ticks on, i.e. 6375, but it's not. It's at 6547 -- off by 172.
- t=0 is not the frame it should be. The frame with the dividing line perfectly vertical starts at 23214 -- off by 786 (which is more than the expected length of two frames!)
- One might hope that the frame for t=12000, while inevitably wrong, would at least be the correct 12000 away from the t=0 frame. Nope. 12785, which is 785* away from correct, and 1571 away from the "expected wrong value" of 11214.
So it looks like however the clock is coded, it's not as simple as "divide the day by the number of frames". Maybe there's something wrong with my specific copy of Minecraft... I suppose the logical next test is to use my unmodified .jar and see if that helps.
EDIT: Nope. Still doing exactly the same even with the vanilla .jar file.
Another edit: Actually, I suspect I know what the issue is. The (default) clock face is exactly half day half night. Which isn't what the cycle is like! I took a look at how many frames long each hour was (now with twice as many frames for greater precision), and broadly speaking, they're fewer frames long closer to midday, and more frames long closer to midnight. Which means it must be, essentially, running different framerates at different times of day -- advancing more frames at night because it has to get through the same number of frames in less time. That's a good thing when your dial is not representative of the true day/night split, but a very bad thing for displays that are totally regular throughout the cycle.
In any case, having now measured it that way around (what frames correspond to the tick times), I'm redoing the texture with the frames based on that. Should work, and should always be accurate within five seconds/100 ticks. Or seven seconds because of the framerate... or something... eh, it's less than ten seconds either way, good enough. I may do even more frames, for even greater accuracy, at some later stage if I can be bothered
I have edited this post far too many times:
If anyone's at all interested, I did a 1200 frame animation, so each frame would correspond to one second if it were linear. And here's what the actual frames per second of the animation looks like over the course of the day:
As I noted, it's higher fps at night, and lower in the day. And this is why a linear animation is doomed to fail.