Keeping time 2: Capacitors?

In previous post I talked about ways how you can make your embedded design to keep time, even when not powered.

Mostly I spoke of coin cell batteries as backup source. There is also other options, most common being capacitors and super- or ultracapacitors, and possibly some others. I'll just ignore bigger lithium- and other larger batteries here, since those generally imply that your device is primarily powered from that battery and thus the same battery will be used to keep time when device is "off", or minimal power drain mode.

There are pros and cons with each type of energy storage. The short list, as I see it;

• Large batteries (Li-ion and others): large, expensive, require charging circuitry. Not great for backup supply (these usually have tendency to self-discharge at certain rate), but this is the choice when you want your design to operate fully without external power.
• Lithium coin cells and equivalents: relatively small and inexpensive and they carry lots of energy to keep your clock ticking, up to several years without external powers. Bad side is that they are expensive (if you use them wrong, i.e. waste their power), must be replaced (if you allow them to run empty) and can't really power up your entire design - unless it's very - no, ultra-low power (like TI's MSP430-series)
• Super/ultracapacitors. Compact ones (in millifarad range) can keep your clock running for several days or up to a week or so, and are essentially infinitely rechargeable. So if you expect your product to encounter few days of power outage (but not much longer) occasionally, these might be enough.
• Electrolytic capacitors, few hundreds of microfarads or so. The can keep your clock running for several hours, so useful for common, but short breaks, and they are also very cheap.
• MLCCs - that is, ceramic multilayer caps; tens of microfarads. Now we are down to tens of minutes, but for common but short breaks they will be enough - and they're very cheap too.
• None at all. If your design is connected, you might be able to get away with device fetching current time on startup from internet or other such place. This means that it will take a while (connection latency) before your clock is in time again, and this is assuming that your device can fetch the time when it powers back up immediately.

The times I mention above are very rough estimates, and depend highly on the energy capacity of the power source you are using and power drain of your clock. For your design, you'll just have to read the datasheets (very carefully, as the most important information tends to be hidden away - again, a topic for another day) and do the energy math for yourself.