title: Overflow in std::chrono::duration for remaining time measurement
body: <p>I would like to know, how much time is remaining for an event to happen. I'm using boost::chrono or std::chrono for that.</p>
  
  <p>Basically the algorithm is like that:</p>
  
  <pre><code>using std::chrono; // Just for this example
  auto start = steady_clock::now();
  seconds myTotalTime(10);
  while(true){
    auto remaining = start + myTotalTime - steady_clock::now();
    seconds remainingSecs = duration_cast&lt;seconds&gt;(remaining);
    if(remainingSecs.count() &lt;= 0) return true;
    else print("Remaining time = " + remainingSecs.count()); // Pseudo-Code!
  }
  </code></pre>
  
  <p>Now the following could (theoretically) happen: <code>start</code> is near the end of the period of the clock (IMO there is no notion what <code>0</code> means, so it could be arbitrary).<br>
  Then <code>start + myTotalTime</code> could overflow and the subtraction could underflow.</p>
  
  <p>Even simple things like <code>steady_clock::now() - start</code> could underflow.</p>
  
  <p>For unsigned types this is not a problem. If they were unsigned, then the standard guarantees that I still get the correct number of "units" for <code>steady_clock::now() - start</code> in the case of an overflowed <code>now()</code> and the underflowing subtraction: <code>10 - 250 = 10 + 256 - 255 = 16</code> for 8bit unsigned math.</p>
  
  <p>But AFAIK over/underflow for signed types is undefined behaviour.</p>
  
  <p>Am I missing anything? Why are the duration and especially time_points defined with signed instead of unsigned types?</p>