title: EWS QueryString "received" date off by one day
body: <p>An external process emails messages to an Exchange mailbox. I then have an Exchange Web Services (EWS) 2.0 application to fetch those email messages for subsequent processing. The EWS application is designed to fetch messages received on the current date, eg <code>"received:today"</code> in AQS parlance. The messages, however, are never retrieved - none are returned to the <code>ItemView</code> of the <code>FindItems</code> method:</p>
  
  <pre><code> ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2013);
  // sharedMailbox is a FolderId type set to a valid well-known location not reproduced here
  
   FindItemsResults&lt;Item&gt; findResults = service.FindItems(sharedMailbox,"(subject:flotsam) AND (received:today)",  new ItemView(20));
  </code></pre>
  
  <p>On a lark, changing this date to "received:yesterday" finally caught the desired messages, but an inspection of each message's explicit received date for each of the messages was <em>not</em> <strong><em>yesterday</em></strong>, but <strong><em>today</em></strong>:</p>
  
  <pre><code>    Console.WriteLine(item.DateTimeReceived.ToLocalTime());
      Console.WriteLine(item.DateTimeReceived.ToUniversalTime());
  
  10/24/2016 1:05:38 AM
  10/24/2016 6:05:38 AM
  </code></pre>
  
  <p>I suspected an oddity in the translation of the constants, and opted to provide explicit dates. However, explicitly defining the receipt date in <code>"received:MM/DD/YYYY"</code> form (rather than 'today' or 'yesterday') exhibited the same results:</p>
  
  <pre><code> FindItemsResults&lt;Item&gt; findResults = service.FindItems(sharedMailbox,"(subject:flotsam) AND (received:10/23/2016)",  new ItemView(20));
  </code></pre>
  
  <p>Although the date is <em>yesterday</em>, this code <em>did</em> fetch messages retrieved <em>today</em>, which is 10/24/2016 (<em>not</em> 10/23/2016). Code specifying <em>today</em>, which <em>should</em> fetch the desired messages, actually fetched <em>no</em> messages:</p>
  
  <pre><code> FindItemsResults&lt;Item&gt; findResults = service.FindItems(sharedMailbox,"(subject:flotsam) AND (received:10/24/2016)",  new ItemView(20));
  </code></pre>
  
  <p>In effect, the explicit dates are behaving exactly as the 'received:yesterday' and 'received:today' querystring values, so that implies these constants are simply being mapped to the values I hard-coded.</p>
  
  <p>I then suspected timezone differences, or UTC conversion differences, but our local timezone is <em>behind</em> UTC, meaning that specifying "received:today" should, in reality, work in fetching messages received....today.</p>
  
  <p>I am at a loss to know or understand why we are seeing this single-day discrepancy in fetched messages. What aspect of message date interpretation am I handling incorrectly?</p>
  
  <p><strong>EDIT</strong>: Per suggestion in comments, I modified the <code>FindItems</code> call to use a <code>SearchFilter</code> object, using a <code>DateTime</code> value of <code>Now</code> minus one day (actually, a value <em>24 hours</em> from DateTime.Now. This created a datetime value that crossed into 10/23/2016, and retrieved the messages received <strong>today.</strong> So I cannot be sure that the filter really found the messages because they were received on 10/24, or because the search date range included yesterday (which caused the other searches to work):</p>
  
  <pre><code> SearchFilter sf = new SearchFilter.IsGreaterThan(ItemSchema.DateTimeReceived, new DateTime.Now.AddDays(-1));
  </code></pre>
  
  <p>Taking a cue from this, I modified the filter to use a <code>DateTime</code> without an explicit time element:</p>
  
  <pre><code> SearchFilter sf = new SearchFilter.IsGreaterThan(ItemSchema.DateTimeReceived, new DateTime(2016,10,24));
  </code></pre>
  
  <p>This search filter <em>worked</em>, returning both messages received today. This tends to suggest some semantic hiccup or uncertainty with the 'today' and 'yesterday' keywords. </p>
  
  <p>I would prefer to find an AQS-based solution, if possible, or at least find a better understanding of why the querystring values aren't working as expected.</p>