As I near final release, I was tidying up what happens when one of the quick minute-to-minute transition animations (fade or slide) crosses the boundary between hours. I chose to always render the NEXT minute so that the inbound image can start "arriving" early—by a fraction of a second—to account for the animation duration. That allows the new time to arrive at the actual moment of time change instead of slightly late.

Long story short, not only does that minute-shift, if it happens at :59,  it causes the hour to change too... and at midnight it causes the date to change as well. And the day of the week, which some of my clocks display.

Naturally, changing the day's date can also cause the month to change. And sometimes, that can in turn cause the year to change. Happy New Year!

I wrote code to handle all that—but it won't work unless I can determine the length of each specific month. Which is simple... except for February.

Yep. To make those early minute-to-minute transitions reliable, I have to calculate which years are leap years.

It's not just every 4 years. TIL that once a century, a leap year gets skipped. But once every fourcenturies, the skipped one is NOT skipped—which happened in 2000.

So at midnight on February 28 next year, my users can find out if my regular leap year code works. (If not, at a minute past midnight, the date should correct itself anyway—so keep your eyes peeled at midnight or you'll never know!)

As for the four-century code specifically... that won't get tested until the year 2400. Hooray for replaceable batteries! 

Of course, not all the clocks in Playtime even have an animated transition to worry about. And not all of them display the date. And only two of the clocks (so far) include the month and year. Unless all of those things are true for the clock being shown, leap years don't matter anyway.

But just in case you are using a clock that DOES animate the minutes, and DOES display the date and DOES include the month, and you happen to be looking at the clock between midnight and 59 seconds past (since any issues will self-correct at 1 minute), and you bother to notice the displayed month, and February 28 has just ended, and it's a leap year—be it next year or in four centuries, but NOT in one, two, or three centuries (those leap years get skipped)—I have your back.

Anyone interested in beta testing the 400-year code should contact me by February 20, 2400, at the latest.

(Yes, that's a little Stereo Dock icon, indicating that a dock was detected and you're receiving power. No, I don't have one of those yet to test this! The is one of two clocks in Playtime that displays the battery status—and the month and year. 24-hour time shown here, but 12-hour time is supported as well. And when you choose 12-hour time, the date appears in US format too.)