title: ZonedDateTime comparison: expected: [Etc/UTC] but was: [UTC]
body: <p>I was comparing two dates which seem to be equal, but they contain a different name of zones: one is <code>Etc/UTC</code>, another is <code>UTC</code>. </p>
  
  <p>According to this question: <a href="https://stackoverflow.com/questions/14128574/is-there-a-difference-between-the-utc-and-etc-utc-time-zones">Is there a difference between the UTC and Etc/UTC time zones?</a> - this two zones are the same. But my tests fail:</p>
  
  <pre><code>import org.junit.Test;
  import java.sql.Timestamp;
  import java.time.ZoneId;
  import java.time.ZonedDateTime;
  import static org.junit.Assert.assertEquals;
  
  public class TestZoneDateTime {
  
      @Test
      public void compareEtcUtcWithUtc() {
          ZonedDateTime now = ZonedDateTime.now();
          ZonedDateTime zoneDateTimeEtcUtc = now.withZoneSameInstant(ZoneId.of("Etc/UTC"));
          ZonedDateTime zoneDateTimeUtc = now.withZoneSameInstant(ZoneId.of("UTC"));
  
          // This is okay
          assertEquals(Timestamp.from(zoneDateTimeEtcUtc.toInstant()), Timestamp.from(zoneDateTimeUtc.toInstant()));
          // This one fails
          assertEquals(zoneDateTimeEtcUtc,zoneDateTimeUtc);
  
          // This fails as well (of course previous line should be commented!)
          assertEquals(0, zoneDateTimeEtcUtc.compareTo(zoneDateTimeUtc));
      }
  }
  </code></pre>
  
  <p>The result:</p>
  
  <pre><code>java.lang.AssertionError: 
  Expected :2018-01-26T13:55:57.087Z[Etc/UTC]
  Actual   :2018-01-26T13:55:57.087Z[UTC]
  </code></pre>
  
  <p>More specifically, I would expect, that <code>ZoneId.of("UTC")</code> would be equal to <code>ZoneId.of("Etc/UTC")</code>, but they aren't!</p>
  
  <p>As @NicolasHenneaux <a href="https://stackoverflow.com/a/48463269/1479414">suggested</a>, I should probably use <code>compareTo(...)</code> method. That's good idea, but <code>zoneDateTimeEtcUtc.compareTo(zoneDateTimeUtc)</code> returns <code>-16</code> value, because of this implementation inside <code>ZoneDateTime</code>:</p>
  
  <pre><code>cmp = getZone().getId().compareTo(other.getZone().getId());
  </code></pre>
  
  <p>Assertion result:</p>
  
  <pre><code>java.lang.AssertionError: 
  Expected :0
  Actual   :-16
  </code></pre>
  
  <p>So the problem lies somewhere in <code>ZoneId</code> implementation. But I still would expect that if both zone ids are valid and both designate the same zone, then they <em>should</em> be equal.</p>
  
  <p>My question is: is it a library bug, or I am doing something wrong?</p>
  
  <p><strong>UPDATE</strong></p>
  
  <p>Several people tried to convince me that it is a <em>normal</em> behaviour, and it is <em>normal</em> that the implementation of comparison methods uses <code>String</code> id representation of the <code>ZoneId</code>. In this case I should ask, why does the following test runs okay? </p>
  
  <pre><code>    @Test
      public void compareUtc0WithUtc() {
          ZonedDateTime now = ZonedDateTime.now();
          ZoneId utcZone = ZoneId.of("UTC");
          ZonedDateTime zonedDateTimeUtc = now.withZoneSameInstant(utcZone);
          ZoneId utc0Zone = ZoneId.of("UTC+0");
          ZonedDateTime zonedDateTimeUtc0 = now.withZoneSameInstant(utc0Zone);
  
          // This is okay
          assertEquals(Timestamp.from(zonedDateTimeUtc.toInstant()), Timestamp.from(zonedDateTimeUtc0.toInstant()));
          assertEquals(0, zonedDateTimeUtc.compareTo(zonedDateTimeUtc0));
          assertEquals(zonedDateTimeUtc,zonedDateTimeUtc0);
      }
  </code></pre>
  
  <p>If <code>Etc/UTC</code> <strong>is</strong> the same as <code>UTC</code>, then I see two options:</p>
  
  <ul>
  <li>compareTo/equals method shouldn't use ZoneId id, but should compare their rules</li>
  <li><code>Zone.of(...)</code> is broken and should treat <code>Etc/UTC</code> and <code>UTC</code> as the same time zones. </li>
  </ul>
  
  <p>Otherwise I don't see why <code>UTC+0</code> and <code>UTC</code> work fine.</p>
  
  <p><strong>UPDATE-2</strong> I have reported a bug,  ID : 9052414. Will see what Oracle team will decide.</p>
  
  <p><strong>UPDATE-3</strong> The bug report accepted (don't know will they close it as "won't fix" or not): <a href="https://bugs.openjdk.java.net/browse/JDK-8196398" rel="noreferrer">https://bugs.openjdk.java.net/browse/JDK-8196398</a></p>