To give an example of how this could happen (not saying this is what happened, but I've heard this happened before):

Suppose you left ntpd running and automatically adjusting the clock every hour.

If your clock is running faster than pool.ntp.org, and you are synchronizing to it, you may end up adjusting in the middle of an event. Because your clock is running fast, you would jump back in time, breaking the sequence of time (this is somewhat equivalent to what you see during daylight savings time if you aren't intelligent in the way you handle the backwards hour shift)

In this case, if the adjustment was forward in time, there would be a gap.

My understanding is that ntpd corrects clock drift by replaying milliseconds consecutively, not by actually jumping back.

However I can't remember where I read that and could be totally wrong.

I'm sure there are lots of buggy NTP implementations out there that "adjust the clock every hour", but the way it's supposed to work is by continuously varying the speed of the clock (for example, using adjtime()) to correct any discrepancies. At no point should the clock jump backwards or forwards, or even have milliseconds that are more than X percent longer or shorter than usual.