As Freddy mentioned, it's not usually a problem to get the holiday data. But there's a few more caveats:
- sometimes the market where the security is listed doesn't observe the local holidays
- sometimes the market does observe the holiday but the security doesn't
- sometimes it's the other way around
- not all securities listed on one particular market follow the same rules
- different market places might offer the same security but with different holiday rules
- a lot of markets/securities have half-days too (it's like half a holiday)
A lot of these caveats apply to intraday data only, that's why I'm not going into too much detail here, it depends on where your platform will go. But as you can see, it's more of a classifcation problem in the long run.
We solved the "holiday problem" by inverting it, i.e. we keep track of trading days/hours. In our system the basic entity is a session. A market to us is a collection of these sessions. A security on the other hand has an OPOL market (primary listing) and possibly other markets, and for each such listing there's a collection of (possibly overlapping) sessions. If at a given date/time there is an active session for a security on any market, data should be there.
Now, holidays might either affect markets or sessions. If the market is affected no sessions will be active on that day for securities listed on that market. If a session is affected, all securities attributed with that session will stay inactive (for the duration of that session).
So in this system the rules for sessions clearly dictate if there are and how to find holes in the data (and also the opposite: data comes in even though there's no active trading session).
For the programmatical bit: we use bitsets and edge triggers, whenever a session becomes active its bit is set, whenever it goes inactive the bit is cleared. So for any point in time we can immediately say what sessions are active and through the security<->session association we have immediately all the securities affected.