Way back in Notes 6, Lotus added parameters to @now to support this, but of course, it was a while before my client had Notes 6 installed, so we didn't do anything about it. But a couple of years ago, we revisited the issue and added server-clocking to the application.

Let's recap the new optional parameters to @now:

• flags: [ServerTime] tells @now to go and fetch time from one or more servers, [LocalTimeonError] to fall back to the client clock value if the server is unavailable; combine these as required with a colon.
• servernames: Here you enter a list of servers; if you leave this out, the server hosting the database is the one whose clock value is returned. If you enter more than one server name as a list, you'll get a list, the same size, of clock values returned, and it's always possible that one or more of those is actually the local time, should the corresponding server be unavailable.

However, we discovered quite rapidly that these changes weren't as useful as we'd hoped. We found that the first time any given server's clock time is accessed, the client fetches the server time and then caches it. Any subsequent calls from the same open database session return the cached value, updated by whatever local time has elapsed since the first call. Which means that the server time returned can be "faked" by altering the local clock, or indeed if the local clock doesn't keep good time and the database is open for any length of time, you get different values to those which you'd expect.

The function was intentionally designed this way for performance -- getting the server time takes a while -- so rather than do it all the time, the designers figured that doing it once and then extrapolating for subsequent calls would be OK. We understood the performance issue, but we wanted to be the people who made the choice of when the server time was fetched, given the particular uses made of the application -- it could be left open continuously for days at a time.