[RESOLVED] Adjusting Time

[Shaggy Hiker]

This is a follow-up to a thread some may remember.

I have an app that works against a DB. There could be multiple instances of this app running on multiple computers, in which case they all work against the same DB. The user can take an action on either computer, and the action has to be reflected on any other running apps on other computers. This is done via UDP messages in a peer-to-peer network. What I found was that the system time differences between the systems was causing me some trouble. A user could take an action on one computer, and a different one with a slower clock might not show it because, as far as that system was concerned, the event hadn't happened yet.

Oddly, I had the germ of a solution built into the program years ago. The solution was to have all running apps use the DB time. There were two ways that I could see to do this, one of which was to change all the system times of the various systems to match the time on the DB host machine. That seemed overly intrusive. I wouldn't be just changing something as far as the app was concerned, I'd be changing the system itself. I wouldn't think people would care too much about that, but it could be kind of bad, especially if the DB host had a seriously incorrect clock setting.

The other alternative was for each running app to keep track of how far off it was from the DB time, and adjust that time on the fly. This turned out to be pretty simple to do, since I never used the system time directly in the app. What I was doing instead was creating a time based off of something, which was usually the system time rounded down to the nearest second, but not always (and those cases can be ignored, as the time differential doesn't matter for those cases). The reason I was doing this is that the sub-second resolution of the clock was causing me trouble, and that's how I solved it. However, that meant I had a place where I was creating a time, so I have an excellent place to create a slightly different time.

While most cases will have an offset of only a couple seconds, why stop there? I added the ability to have offsets for year, month, day, hour, minute, and second. When the app gets the time, it can get the time adjusted by the offset. The problem with that is that it is possible to get invalid times. If the offset is -3 seconds, then if the current system second is 0-2, the resulting time has a negative number of seconds, which throws an exception.

Fixing this is pretty straightforward. There are two alternatives. Perhaps the best is to turn the offset into a total number of seconds and add that offset to the date. Another alternative would be to check for those cases where the date would be invalid, but that would mean lots of conditionals, and that would be worse. The key point is that this is the innermost of innermost loops in a fairly time sensitive app. Lots can happen, and I have little control over that, so to keep the app responsive I have tried to keep the innermost core functionality as efficient as possible.

I have to be able to get system time, adjusted by the offset from the DB time, and rounded down to the nearest second, and do so in the most efficient manner possible. The solution I currently have is to figure out the offset in total second between the DB time and the system time. Whenever the app requests the current time, it gets the current time rounded down to the nearest second, and adds the offset seconds to it. This means creating a date object with each call, then adjusting it by N seconds. Is there an alternative that might be more efficient?

[TnTinMN]

While most cases will have an offset of only a couple seconds, why stop there? I added the ability to have offsets for year, month, day, hour, minute, and second. When the app gets the time, it can get the time adjusted by the offset. The problem with that is that it is possible to get invalid times. If the offset is -3 seconds, then if the current system second is 0-2, the resulting time has a negative number of seconds, which throws an exception.

I have to be able to get system time, adjusted by the offset from the DB time, and rounded down to the nearest second, and do so in the most efficient manner possible. The solution I currently have is to figure out the offset in total second between the DB time and the system time. Whenever the app requests the current time, it gets the current time rounded down to the nearest second, and adds the offset seconds to it. This means creating a date object with each call, then adjusting it by N seconds. Is there an alternative that might be more efficient?

I'm more than a bit confused by your description (bolded section in quoted text), but it sounds like you have created your on timekeeping system that somehow correlates back to the system time.

You may have a good reason for doing this, but you are asking for a more efficient way of computing a time synchronized to the DB machine's time. I have to ask why not just compute your DBTimeOffset in ticks and use that? No need for year/ month/day/hour/minute/second.

[Evil_Giraffe]

What makes you think it isn't efficient enough for your purpose?

Also, from your description of the problem with negative seconds, you're keeping the offset in a TimeSpan which you can simply add (or subtract, depending on which way around is +ve) from the current system time, right?

Also, when adjusting the offset, you're keeping track of the last time you emitted and ensuring you never "go back in time" right?

Further, I think you really need to stop worrying about time as defined by a clock (whether or not that's connected to reality), and figure just what the heck your proper abstraction is, because you shouldn't be having these issues.

[dbasnett]

I have to ask the obvious question, are all the machines using a NTP time service to set their clocks?

Glad to see you weren't blown away.

[Shaggy Hiker]

Blown away by what? We had some breezes, but nothing much, nor was there a forecast for much that I was aware of.

The systems may not have any network connection, so system time is all I'm dealing with.

@EG: That's probably true, as you noted before. Generally, we care about the time when things happen, but only at a very coarse scale. The events I am recorded are events that generally need to be tied to a date, but not a time at all. Some of them do need to be tied to time, but even then only down to morning or evening. I'm being way too precise, in general. There are a couple things that need to be before X and just barely. Since this is a plug-in system, I can't be certain what other things could come before them, or whether they are five minutes earlier or hours earlier. Using a sequential id would have worked, but it's way too late for that.

The solution I described works fine, and is probably pretty efficient. After all, the only thing I am doing is taking the system time and adding a constant number of seconds. There may be a better way, but it would require a pretty extensive re-write to switch from using time to using an arbitrary sequence that could be turned into time on demand.