| Date/Time value precision |
All date/time values stored in the Meridian Enterprise vault are in UTC. But when a date/time value round-trips from COM to .NET it is converted to a System.DateTime type value that is DateTimeKind.Unspecified. That kind indicates that a value is either local time or UTC. Before performing arithmetic on such time values, they must be converted to UTC.
The SDK library helps the developer to avoid manual conversion of date/time values; all methods and properties that have a return value of System.DateTime type return a DateTimeKind.Utc value. If a date/time value is passed in, then it will be converted to UTC implicitly before being passed to Meridian Enterprise. This behavior does not apply to methods that operate with an array of values (BCRepository.SavePropertyValues, BCRepository.LoadPropertyValues, and so on). You should manually convert such values to UTC by using the Utils.ToUniversalTime method defined in the SDK library.
Furthermore, internally, the .NET Common Language Runtime (CLR) represents a date/time value differently than OLE/COM does. It results in a loss of precision when a date/time value round-trips from COM to .NET (the difference is less than 1 millisecond).
For example, in the .NET API you can’t use a BCBaseline.MomentDate property to open a repository at exactly the same moment in time when a baseline was made (the same issue exists for a document revision). This is because the property returns a date/time value that slightly differs from the actual date of the baseline. Instead, you should use the BCBaseline.ID property to identify the baseline.
Proceed with extra care when working with the date/time of revisions, baselines, or any other objects.