1
Vote

Handling Timestamps (IClientLogEntry.OccuredAt)

description

Why not send time in UTC so that timezone is irrelevant?

comments

JayCincotta wrote Apr 9, 2010 at 8:23 PM

For logging it is very helpful to compare the timestamps on the client with timestamps on the server. On the client side, the data could be stored using DateTime.UtcNow
http://msdn.microsoft.com/en-us/library/system.datetime.utcnow(VS.95).aspx

One the server, the timestamps could be converted back to local time with DateTime.ToLocalTime
http://msdn.microsoft.com/en-us/library/system.datetime.tolocaltime.aspx

This would eliminate problems with timezones, but doesn't address an important second issue: clock synchronization.

In a corporate environment you might safely trust that everyone's computer uses a standard IT image that includes W32Time syncronization. But that assumption is not reasonable in general. Having some level of time synchronization between server and client would make the timestamps received from the client much more useful.

Don't worry about millisecond level precision, but avoid being off by minutes. If the header of each message from client to server included a UTC timestamp, the server receiving it could calculate an offset based on the UTC time received (i.e. for simplicity, assume zero transfer time). That offset could be applied to all the timestamps in the IClientLogEntry records before dispatching them. Or, the offset could otherwise be made available to the code consuming the messages.

wrote Feb 14, 2013 at 1:06 AM