title: Optimizing alternatives to DateTime.Now
body: <p>A colleague and I are going back and forth on this issue and I'm hoping to get some outside opinions as to whether or not my proposed solution is a good idea.</p>
  
  <p>First, a disclaimer: I realize that the notion of "optimizing <code>DateTime.Now</code>" sounds crazy to some of you. I have a couple of pre-emptive defenses:</p>
  
  <ol>
  <li>I sometimes suspect that those people who always say, "Computers are fast; readability <em>always</em> comes before optimization" are often speaking from experience developing applications where performance, though it may be <em>important</em>, is not <strong>critical</strong>. I'm talking about needing things to happen as close to instantaneously as possible -- like, within nanoseconds (in certain industries, this <em>does</em> matter -- for instance, real-time high-frequency trading).</li>
  <li>Even with that in mind, the alternative approach I describe below is, in fact, quite readable. It is not a bizarre hack, just a simple method that works reliably and fast.</li>
  <li>We <strong>have</strong> runs tests. <code>DateTime.Now</code> <strong>is</strong> slow (relatively speaking). The method below <strong>is</strong> faster.</li>
  </ol>
  
  <p>Now, onto the question itself.</p>
  
  <p>Basically, from tests, we've found that <code>DateTime.Now</code> takes roughly 25 ticks (around 2.5 microseconds) to run. This is averaged out over thousands to millions of calls, of course. It appears that the first call actually takes a significant amount of time and subsequent calls are much faster. But still, 25 ticks is the average.</p>
  
  <p>However, my colleague and I noticed that <code>DateTime.UtcNow</code> takes substantially less time to run -- on average, a mere 0.03 microseconds.</p>
  
  <p><em>Given that our application will never be running while there is a change in Daylight Savings Time</em>, my suggestion was to create the following class:</p>
  
  <pre><code>public static class FastDateTime {
      public static TimeSpan LocalUtcOffset { get; private set; }
  
      public static DateTime Now {
          get { return DateTime.UtcNow + LocalUtcOffset; }
      }
  
      static FastDateTime() {
          LocalUtcOffset = TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now);
      }
  }
  </code></pre>
  
  <p>In other words, determine the UTC offset for the local timezone <strong>once</strong> -- at startup -- and from that point onward leverage the speed of <code>DateTime.UtcNow</code> to get the current time a lot faster via <code>FastDateTime.Now</code>.</p>
  
  <p>I could see this being a problem if the UTC offset changed during the time the application was running (if, for example, the application was running overnight); but as I stated already, in <em>our</em> case, that will not happen.</p>
  
  <p>My colleague has a different idea about how to do it, which is a bit too involved for me to explain here. Ultimately, <em>as far as I can tell</em>, both of our approaches return an accurate result, mine being slightly faster (~0.07 microseconds vs. ~0.21 microseconds).</p>
  
  <p>What I want to know is:</p>
  
  <ol>
  <li>Am I missing something here? Given the abovementioned fact that the application will only run within the time frame of a single date, is <code>FastDateTime.Now</code> safe?</li>
  <li>Can anyone else perhaps think of an even <em>faster</em> way of getting the current time?</li>
  </ol>