I don't actually have hardware for the crazy clock yet, but I've been simulating it on the bench with a PDIP ATTiny85 and LEDs.
My original inspiration was this clock on Tindie. The seller includes a video showing the clock in action. It's certainly a crazy clock. But I'm not sure the psychology is exactly right. The original clock of Lord Vetinari was designed to subtly play with the mind of the observer. I think there's a better way.
I think to really achieve the goal, the clock should just be quite a bit more regular. After all, subtlety is the goal.
What I've come up with is the notion of periods of time when the clock is ticking double-time and periods of time when it's ticking half-time. As long as the total amount of double-time ticking is exactly matched by periods of half-time ticking, the accuracy of the clock will be unchanged. It's also a goal to insure that the casual observer sees nothing particularly untoward. He might on some unconscious level feel like time is rushing or crawling. But the accuracy of the clock, of course, must be unaffected.
What I came up with is the notion of an "instruction list." The list is periodically constructed and filled with pairs of instruction codes representing a period of half-time, double-time or normal-time. Each pair is either two normal-time instructions or a half-time/double-time pair. Once filled, the instruction list is shuffled. Constructing the list this way will result in apparently random ticking, but at the end of each list, the actual number of ticks will be correct.
Each instruction will be followed for a random - but even - number of seconds (it must be even so that there are no fencepost errors when ticking at half-time). Picking a moderate length of time (10-20 seconds or so) will make the clock appear to be more normal at first glance. But, of course, for the clock to remain accurate, each instruction must be followed for the same amount of time for a single list of instructions.
The hardware has a 16.384 MHz crystal, but the pre-scaler is set to 32, yielding a CPU clock of 512 kHz (if you set the clock slower than that, then uploading firmware becomes problematic - apparently the prescaler is not cleared before programming starts, which has got to be a bug). Timer 0 is configured with the 1024 pre-scaling setting, so it will count at 500 Hz. Setting it up for CTC mode and setting the counter compare register to 50 will result in an interrupt source of 10 Hz. The firmware will use SLEEP_MODE_IDLE and operate by simply entering sleep_mode() regularly to mark time.
In principle, the CPU should spend most of its time in IDLE mode, with a 512 kHz system clock and a 3.3 volt Vcc. According to the datasheet, that should result in a power consumption of only 100 µA. If you assume that the ticking of the clock consumes 10 mA for 30 ms, 3600 times per hour, you wind up with a single AA battery lasting around 90 days. Certainly not as long as a straight-up clock would last, but 90 days isn't at all unreasonable. As a side-effect, however, the boost converter will allow the system to run all the way down to a battery voltage of 0.7 volts, by which point the battery will be well and truly dead.
The firmware is up on Github.