How to use EventStore to built up new application views in praxis?

Yes, something similar has been asked at least a couple of times before. Thus I know the answer: You just replay the events on the new handler, simple. But having a go at an actual implementation raises some questions.

I'm using JOlivier's EventStore which seems nice. For starters I'll ignore the concept of SnapShots and just look at a way to get my events out. All I could get going is this code:

var commitList = Store.GetFrom(DateTime.UtcNow.AddSeconds(-1));
foreach (var commit in commitList)
{
    foreach (var comittedEvent in commit.Events)
    {
        if (comittedEvent.Body is SomeDomainEvent)
            Console.WriteLine(string.Format("Found interesting event: {0}", ((SomeDomainEvent)comittedEvent.Body).Value));
    }
}

First question here is of course: Is this the way to do it? I'm having trouble using the parameter for "GetFrom" since it's just a DateTime and I can't be sure that all servers are in sync timewise. What if the the clock on one server is 1 minut behind another? Or ½ hour? I'm also using NServiceBus so the new handler queue will pile up events from a certain point in time - but how can I be 100% sure that there isn't 10 seconds missing here? Please tell me how you get events out of the EventStore while being 100% (not 99%) sure that the new application view is completely in sync when started开发者_开发问答.

Also: Do you create a special import method in your code? I mean, suppose the handler in my new application sends out an email when it handles "SomeDomainEvent". I don't want it to send out emails for all 10.000 old events. How do you do this "import" in praxis/code?

---

1. Add idempotency to the mix. Jonathan talks about this in his blog posts about the EventStore project (v2). At-least once message delivery combined with idempotency will make sure you don't handle the same message twice. As such, being off by a few minutes (even a half an hour) doesn't really matter. You'd need to integrate this idempotency behavior in your NSB handlers as well (e.g. as a first handler).
2. If your handlers have side-effects (which seems odd as I was under the impression you were replaying to get a new report/view) then there's no harm in using current time and event time to decide if emails should be sent for stuff from the past. Alternatively, you could compose your handlers (using an IoC) with a NullEmailSender:IEmailSender that does nothing (because you know the path you're on is one of replaying the past).