Use TimeUnits for sort key calculations

The unspecified units were confusing when writing tests around these
values, so be explicit about units in variable names and quantities
for conversion.

Use Ints.checkedCast so we fail fast when inserting a change 4000+
years in the future rather than having it not show up in search
results.

Correct the sort key epoch time, which likely had a timezone error
when initially calculated:

$ python -c 'import datetime; print datetime.datetime.fromtimestamp(1222819200L)'
2008-09-30 17:00:00

This mistake does not affect any data; the comment in the code was
just confusingly incorrect.

Change-Id: I6d8bcf4985e91c3d115002db42642049da8c708f

gerrit-server/src/test/java/com/google/gerrit/server/query/change/AbstractQueryChangesTest.java

@@ -14,6 +14,9 @@
 
 package com.google.gerrit.server.query.change;
 
+import static java.util.concurrent.TimeUnit.MILLISECONDS;
+import static java.util.concurrent.TimeUnit.MINUTES;
+import static java.util.concurrent.TimeUnit.DAYS;
 import static org.junit.Assert.assertEquals;
 import static org.junit.Assert.assertTrue;
 
@@ -85,7 +88,9 @@ public abstract class AbstractQueryChangesTest {
   protected Account.Id userId;
   protected CurrentUser user;
   protected int clockStepMs = 1;
-  private long ts = ChangeUtil.SORT_KEY_EPOCH * 1000;
+  private long clockMs =
+      MILLISECONDS.convert(ChangeUtil.SORT_KEY_EPOCH_MINS, MINUTES)
+      + MILLISECONDS.convert(60, DAYS);
 
   protected abstract Injector createInjector();
 
@@ -416,8 +421,8 @@ public abstract class AbstractQueryChangesTest {
 
     Change change = new Change(new Change.Key(key), id, ownerId,
         new Branch.NameKey(project, branch));
-    change.setLastUpdatedOn(new Timestamp(ts));
-    ts += clockStepMs;
+    change.setLastUpdatedOn(new Timestamp(clockMs));
+    clockMs += clockStepMs;
     return changeFactory.create(
         projectControlFactory.controlFor(project,
           userFactory.create(ownerId)).controlFor(change).getRefControl(),