Avoid base::Time::FromJavaTime() when not dealing with Java.

base/time/time.h

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // Time represents an absolute point in coordinated universal time (UTC),
 // internally represented as microseconds (s/1,000,000) since the Windows epoch
 // (1601-01-01 00:00:00 UTC). System-dependent clock interface routines are
 // defined in time_PLATFORM.cc. Note that values for Time may skew and jump
 // around as the operating system makes adjustments to synchronize (e.g., with
 // NTP servers). Thus, client code that uses the Time class must account for
@@ skipping 474 matching lines @@
   // Converts the timespec structure to time. MacOS X 10.8.3 (and tentatively,
   // earlier versions) will have the |ts|'s tv_nsec component zeroed out,
   // having a 1 second resolution, which agrees with
   // https://developer.apple.com/legacy/library/#technotes/tn/tn1150.html#HFSPlusDates.
   static Time FromTimeSpec(const timespec& ts);
 #endif
 
   // Converts to/from the Javascript convention for times, a number of
   // milliseconds since the epoch:
   // https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/getTime.
+  // Consider only using this when dealing with Javascript, and using

[miu, 2017/05/10 21:43:02]

Actually, I'm trying to eliminate all uses of From/ToInternalValue()
 (interesting discussion in http://crbug.com/634507). People use them to cheat
the typing system more often than for wire-format serialization. This has and
continues to cause lots of hard-to-catch bugs, exactly what strong typing of our
time data and math is meant to prevent.

FWIW, this isn't the first time we've had issues with these "java time
conversion" functions. ToJsTime() is inconsistent with FromJsTime() because
folks decided to make the perfectly valid "0" be a representation of null only
in ToJsTime(). So, it's possible for a time math expression to correctly
evaluate to zero, but then after conversion to JS time, it'll be erroneously
interpreted as null. :-/

There was an earlier attempt to fix this that had to be rolled-back due to too
much interweaved dependence on this behavior. Nevertheless, I really want to
kill these and force the platform glue (e.g. between Blink and Chromium base) to
deal with any special conversions. Also, now that we have base::Optional, it
probably makes sense to get rid of is_null() in these time classes; which would
allow "0" to be a valid non-null result.

I'm curious: Can you point me to examples of where you found these were being
misused for serialization? I'd like to better understand the use cases (outside
of Blink<-->Chromium time type conversion).

+  // FromInternalValue()/ToInternalValue() for serialization.
   static Time FromJsTime(double ms_since_epoch);
   double ToJsTime() const;
 
   // Converts to/from Java convention for times, a number of
   // milliseconds since the epoch.
+  // Consider only using this when dealing with Java, and using
+  // FromInternalValue()/ToInternalValue() for serialization.
   static Time FromJavaTime(int64_t ms_since_epoch);
   int64_t ToJavaTime() const;
 
 #if defined(OS_POSIX)
   static Time FromTimeVal(struct timeval t);
   struct timeval ToTimeVal() const;
 #endif
 
 #if defined(OS_MACOSX)
   static Time FromCFAbsoluteTime(CFAbsoluteTime t);
@@ skipping 334 matching lines @@
   static void WaitUntilInitializedWin();
 #endif
 };
 
 // For logging use only.
 BASE_EXPORT std::ostream& operator<<(std::ostream& os, ThreadTicks time_ticks);
 
 }  // namespace base
 
 #endif  // BASE_TIME_TIME_H_