title: Dealing with how MongoDB stores DateTime when used with Service Locator Pattern
body: <p>My colleague and I are at an impasse in a debate and other's input would be greatly appreciated.</p>
  
  <p>We utilize the Service Locator Pattern and a common interface to abstract all of our data access so we can easily swap between different data sources as our needs change.  Our calling code has no indication of where the data is being stored or how.  It simply accesses the data via the service it is fed from the service registry.</p>
  
  <p>The issue we are debating occurs when we have DateTime fields on an object and store it to a MongoDB datasource.</p>
  
  <p>What I have noticed is that when we have an object in C# with a DateTime it appears as the correct time.  When we log into our MongoDB server with MongoVUE to inspect the object it shows the correct time.  But when we retrieve the object the DateTime is now in UTC.  This obviously creates issues when comparing a DateTime in memory to one in an object that has been retrieved from the MongoDB data source.</p>
  
  <p>I understand that Mongo stores DateTime internally as UTC time.  I even understand why it might be returning UTC when you call it.</p>
  
  <p>Here is where the debate begins.</p>
  
  <p>It's been suggested that this is simply a cosmetic issue and only a problem when displaying dates.  Thus we should simply call .ToLocalTime within the interface layer.  I disagree and assert that this dangerously breaks the layers of abstraction we have created in implementing the Service Locator Pattern.  It also raises questions regarding interaction with those date times as it pertains to triggering other events.</p>
  
  <p>What I have read else where is that we should be storing our times as string, specifically as some standard of UTC format.  In this manner the interface layer doesn't know or care how the DateTime is stored and neither does our object since every data source would store that string in the same manner.  </p>
  
  <p>I've had success with doing this using the ISO 1806 format but my colleague feels this is a 'hacky' fix and that using the .toLocalTime is the appropriate way to deal with this situation.</p>
  
  <p>I am interested in what others have to say on the topic.</p>
  
  <p>Thank you in advance for your input.</p>