Fuchsia port of base/time, with some refactoring of POSIX time modules.

Fuchsia port of base/time, with some refactoring of POSIX time modules.

Uses Magenta's mx_time_get() system call to implement base::Time::Now(),
base::TimeTicks::Now(), and base::ThreadTicks::Now(). All other time
implementation uses the POSIX-compatible API.

As part of this change, it became necessary to do a little clean-up and
fork time_posix.cc into three separate files: time_conversion_posix.cc,
time_exploded_posix.cc, and time_now_posix.cc. The code in these files
was not modified, sans some #ifdef's that were no longer necessary (and
some `git cl format` indentation changes).

Then, the BUILD file includes only the needed implementation files for
each platform:

1. Fuchsia: time_fuchsia.cc, time_conversion_posix.cc and
time_exploded_posix.cc.

2. Mac/IOS: time_mac.cc and time_conversion_posix.cc.

3. All other POSIX platforms (such as CrOS, Android, and Linux): The
three time_*_posix.cc files.

Testing notes: Since base_unittests doesn't compile yet, I could only
confirm that the base/time/* code changes compile on Fuchsia. That said,
base_unittests compiles and runs successfully on all other platforms.

BUG=706592
Review-Url: https://codereview.chromium.org/2891583002
Cr-Commit-Position: refs/heads/master@{#473032}
Committed: https://chromium.googlesource.com/chromium/src/+/eb6e744f08cc8087eb7836753d98d599c28a80f7

[miu, 2017-05-16 22:38:33]

Description was changed from

==========
Fuchsia port of base/time, with some refactoring of POSIX time modules.

Uses Magenta's mx_time_get() system call to implement base::Time::Now(),
base::TimeTicks::Now(), and base::ThreadTicks::Now(). All other time
implementation uses the POSIX-compatible API.

As part of this change, it became necessary to do a little clean-up and
fork time_posix.cc into three separate files: time_conversion_posix.cc,
time_exploded_posix.cc, and time_now_posix.cc. Then, the BUILD file
includes only the needed implementation files for each platform:

1. Fuchsia: time_fuchsia.cc, time_conversion_posix.cc and
time_exploded_posix.cc.

2. Mac/IOS: time_mac.cc and time_conversion_posix.cc.

3. All other POSIX platforms (such as CrOS, Android, and Linux): The
three time_*_posix.cc files.

Testing notes: Since base_unittests doesn't compile yet, I could only
confirm that the base/time/* code changes compile on Fuchsia. That said,
base_unittests compiles and runs successfully on all other platforms.

BUG=706592
==========

to

==========
Fuchsia port of base/time, with some refactoring of POSIX time modules.

Uses Magenta's mx_time_get() system call to implement base::Time::Now(),
base::TimeTicks::Now(), and base::ThreadTicks::Now(). All other time
implementation uses the POSIX-compatible API.

As part of this change, it became necessary to do a little clean-up and
fork time_posix.cc into three separate files: time_conversion_posix.cc,
time_exploded_posix.cc, and time_now_posix.cc. The code in these files
was not modified, sans some #ifdef's that were no longer necessary (and
some `git cl format` indentation changes).

Then, the BUILD file includes only the needed implementation files for
each platform:

1. Fuchsia: time_fuchsia.cc, time_conversion_posix.cc and
time_exploded_posix.cc.

2. Mac/IOS: time_mac.cc and time_conversion_posix.cc.

3. All other POSIX platforms (such as CrOS, Android, and Linux): The
three time_*_posix.cc files.

Testing notes: Since base_unittests doesn't compile yet, I could only
confirm that the base/time/* code changes compile on Fuchsia. That said,
base_unittests compiles and runs successfully on all other platforms.

BUG=706592
==========

[miu, 2017-05-16 22:40:22]

Patchset #1 (id:1) has been deleted

[miu, 2017-05-16 22:40:33]

The CQ bit was checked by miu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-16 22:42:52]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-17 00:42:27]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-17 00:42:28]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[miu, 2017-05-17 01:36:54]

Patchset #1 (id:20001) has been deleted

[miu, 2017-05-17 01:39:02]

The CQ bit was checked by miu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-17 01:40:55]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[miu, 2017-05-17 01:44:28]

miu@chromium.org changed reviewers:
+ dsinclair@chromium.org, pasko@chromium.org, thestig@chromium.org

[miu, 2017-05-17 01:44:28]

thestig: PTAL at base/*.

dsinclair: Please RS content/browser/tracing/*.

pasko: Please RS tools/resource_prefetch_predictor/*.

[commit-bot: I haz the power, 2017-05-17 04:47:25]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-17 04:47:26]

Dry run: Try jobs failed on following builders:
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[Lei Zhang, 2017-05-17 08:34:17]

Exciting!

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn
File base/BUILD.gn (left):

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn#oldcode927
base/BUILD.gn:927: "time/time_mac.cc",
This has the advantage of the files are mostly listed together and almost never
repeated. Do we want to keep it like this, let the default
sources_assignment_filter rules in build/config/BUILDCONFIG.gn do their thing,
and tweak the sources afterwards?

i.e.
1) List everything here.
2) Exclude time_exploded_posix.cc and time_now_posix.cc just below line 1468.
3) Add a new conditional rule to exclude time_now_posix.cc for Fuchsia.

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
File base/time/time_conversion_posix.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
base/time/time_conversion_posix.cc:1: // Copyright (c) 2012 The Chromium
Authors. All rights reserved.
No (c) and 2017 since this is a new file?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia.cc
File base/time/time_fuchsia.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:16: CHECK(nanos_since_unix_epoch != 0);
We handle gettimeofday() failures in time_now_posix.cc. Should we be consistent
one way or the other?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:17: const mx_time_t usec_since_unix_epoch =
What is mx_time_t underneath? Can we get away with making this int64_t to avoid
the static_casts?

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
File tools/resource_prefetch_predictor/prefetch_predictor_tool.py (right):

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
tools/resource_prefetch_predictor/prefetch_predictor_tool.py:87: # For the
offset, see kTimeTToMicrosecondsOffset in base/time/time_posix.cc.
base/time/time_posix.cc doesn't exist anymore.

[pasko, 2017-05-17 09:12:18]

On 2017/05/17 01:44:28, miu wrote:
> thestig: PTAL at base/*.
> 
> dsinclair: Please RS content/browser/tracing/*.
> 
> pasko: Please RS tools/resource_prefetch_predictor/*.

I am not an owner here, cannot RS, sorry

[Lei Zhang, 2017-05-17 09:19:53]

On 2017/05/17 09:12:18, pasko wrote:
> On 2017/05/17 01:44:28, miu wrote:
> > thestig: PTAL at base/*.
> > 
> > dsinclair: Please RS content/browser/tracing/*.
> > 
> > pasko: Please RS tools/resource_prefetch_predictor/*.
> 
> I am not an owner here, cannot RS, sorry

But
https://chromium.googlesource.com/chromium/src/+/56387aa57bc11d0f969c5bb9824a...
says you are.

[pasko, 2017-05-17 13:22:49]

On 2017/05/17 09:19:53, Lei Zhang wrote:
> On 2017/05/17 09:12:18, pasko wrote:
> > On 2017/05/17 01:44:28, miu wrote:
> > > thestig: PTAL at base/*.
> > > 
> > > dsinclair: Please RS content/browser/tracing/*.
> > > 
> > > pasko: Please RS tools/resource_prefetch_predictor/*.
> > 
> > I am not an owner here, cannot RS, sorry
> 
> But
>
https://chromium.googlesource.com/chromium/src/+/56387aa57bc11d0f969c5bb9824a...
> says you are.

oh, oops, embarrassing, sorry, I looked at something completely different. Will
take a look now.

[dsinclair, 2017-05-17 13:29:53]

lgtm

content/browser/tracing LGTM.

[pasko, 2017-05-17 13:34:25]

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
File tools/resource_prefetch_predictor/prefetch_predictor_tool.py (right):

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
tools/resource_prefetch_predictor/prefetch_predictor_tool.py:87: # For the
offset, see kTimeTToMicrosecondsOffset in base/time/time_posix.cc.
On 2017/05/17 08:34:17, Lei Zhang wrote:
> base/time/time_posix.cc doesn't exist anymore.

this was explaining where the odd offset constant is coming from. You are moving
it to base/time/time.h via constexpr. Let's then reference time.h then?

[miu, 2017-05-18 02:49:50]

The CQ bit was checked by miu@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-05-18 02:51:00]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[miu, 2017-05-18 02:52:38]

thestig/pasko: Addressed your comments. PTAL.

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn
File base/BUILD.gn (left):

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn#oldcode927
base/BUILD.gn:927: "time/time_mac.cc",
On 2017/05/17 08:34:16, Lei Zhang wrote:
> This has the advantage of the files are mostly listed together and almost
never
> repeated. Do we want to keep it like this, let the default
> sources_assignment_filter rules in build/config/BUILDCONFIG.gn do their thing,
> and tweak the sources afterwards?

I was discussing this with thakis@ at on the code review that added the Fuchsia
build config. The advice I got there was that we want to remove the use of
sources_assignment_filter in the long-term, and instead explicitly "source +=
[...]" files for each platform. To be fair, I'm not sure if there was an
official decision on this, but scottmg@ agreed and also mentioned Brett had made
similar comments.

If you're curious, here's the discussion on that:
https://codereview.chromium.org/2784063002/#msg54

Also, FWIW, the top of this particular BUILD.gn file has a related comment, that
states we should prefer to mention files in more than one list so that it's more
clear under which conditions it will be built.

Sound good to you, to leave it as I have it now?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
File base/time/time_conversion_posix.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
base/time/time_conversion_posix.cc:1: // Copyright (c) 2012 The Chromium
Authors. All rights reserved.
On 2017/05/17 08:34:17, Lei Zhang wrote:
> No (c) and 2017 since this is a new file?

Even with git similarity at 1%, I was unable to make git see this file as a
branch from the original time_posix.cc. I think it's because, in git, the
concept is a "file rename" and so renames can only apply to one file per patch.

So, I'm happy to change to 2017. However, let me ask you again to double-check:
Under the assumption that this is a branch from an existing file (no new code,
only some chunks of code deleted), should I use the old or new copyright year?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia.cc
File base/time/time_fuchsia.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:16: CHECK(nanos_since_unix_epoch != 0);
On 2017/05/17 08:34:17, Lei Zhang wrote:
> We handle gettimeofday() failures in time_now_posix.cc. Should we be
consistent
> one way or the other?

Done (changes to time_now_posix.cc, to not tolerate failures). Notes on why I
changed things the way I did:

1. Given recent discussion on chromium-dev@, the CHECK() is much more the
preferred style over "if (some expression) { NOTREACHED(); }".

2. I re-examined the POSIX documentation for clock_gettime() and gettimeofday().
Based on the description of the return values and all the possible error codes,
only a bug in our code (e.g., bad pointer to struct) should ever trip an error.
Also, we check at compile-time that the clock ID argument is supported by the
platform. Thus, CHECK() should be appropriate.

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:17: const mx_time_t usec_since_unix_epoch =
On 2017/05/17 08:34:17, Lei Zhang wrote:
> What is mx_time_t underneath? Can we get away with making this int64_t to
avoid
> the static_casts?

Good point. I had looked into that, and it's uint64_t.

I am being very pedantic about where the unsigned math is being done versus the
signed math because it scares me to depend on the subtle implicit conversion
rules of the C++ language. ;-) (It has bitten me before!) For example, OTOH, I
don't know what gets implicitly converted when an unsigned 64-bit int is divided
by a signed 64-bit int. The numerator? The denominator? Also, is the result of
the expression an unsigned or signed type?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_mac.cc
File base/time/time_mac.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_mac.cc#n...
base/time/time_mac.cc:214: kTimeTToMicrosecondsOffset -
Note: Trybot unit tests caught my erroneous replacement here. Fixed in next
patchset.

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
File tools/resource_prefetch_predictor/prefetch_predictor_tool.py (right):

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
tools/resource_prefetch_predictor/prefetch_predictor_tool.py:87: # For the
offset, see kTimeTToMicrosecondsOffset in base/time/time_posix.cc.
On 2017/05/17 13:34:25, pasko wrote:
> On 2017/05/17 08:34:17, Lei Zhang wrote:
> > base/time/time_posix.cc doesn't exist anymore.
> 
> this was explaining where the odd offset constant is coming from. You are
moving
> it to base/time/time.h via constexpr. Let's then reference time.h then?

Done.

https://codereview.chromium.org/2891583002/diff/40001/tools/resource_prefetch...
tools/resource_prefetch_predictor/prefetch_predictor_tool.py:87: # For the
offset, see kTimeTToMicrosecondsOffset in base/time/time_posix.cc.
On 2017/05/17 08:34:17, Lei Zhang wrote:
> base/time/time_posix.cc doesn't exist anymore.

Done.

[commit-bot: I haz the power, 2017-05-18 07:26:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-18 07:26:27]

Dry run: This issue passed the CQ dry run.

[pasko, 2017-05-18 11:17:59]

tools/resource_prefetch_predictor lgtm

[Lei Zhang, 2017-05-18 19:06:13]

lgtm

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn
File base/BUILD.gn (left):

https://codereview.chromium.org/2891583002/diff/40001/base/BUILD.gn#oldcode927
base/BUILD.gn:927: "time/time_mac.cc",
On 2017/05/18 02:52:38, miu wrote:
> On 2017/05/17 08:34:16, Lei Zhang wrote:
> > This has the advantage of the files are mostly listed together and almost
> never
> > repeated. Do we want to keep it like this, let the default
> > sources_assignment_filter rules in build/config/BUILDCONFIG.gn do their
thing,
> > and tweak the sources afterwards?
> 
> I was discussing this with thakis@ at on the code review that added the
Fuchsia
> build config. The advice I got there was that we want to remove the use of
> sources_assignment_filter in the long-term, and instead explicitly "source +=
> [...]" files for each platform. To be fair, I'm not sure if there was an
> official decision on this, but scottmg@ agreed and also mentioned Brett had
made
> similar comments.
> 
> If you're curious, here's the discussion on that:
> https://codereview.chromium.org/2784063002/#msg54
> 
> Also, FWIW, the top of this particular BUILD.gn file has a related comment,
that
> states we should prefer to mention files in more than one list so that it's
more
> clear under which conditions it will be built.
> 
> Sound good to you, to leave it as I have it now?

I've always found the sources_assignment_filter to be convinent. Oftentimes, but
not always, it does the right thing. But sure, let's leave this as is, given the
comments at the top of the file.

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
File base/time/time_conversion_posix.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_conversi...
base/time/time_conversion_posix.cc:1: // Copyright (c) 2012 The Chromium
Authors. All rights reserved.
On 2017/05/18 02:52:38, miu wrote:
> On 2017/05/17 08:34:17, Lei Zhang wrote:
> > No (c) and 2017 since this is a new file?
> 
> Even with git similarity at 1%, I was unable to make git see this file as a
> branch from the original time_posix.cc. I think it's because, in git, the
> concept is a "file rename" and so renames can only apply to one file per
patch.
> 
> So, I'm happy to change to 2017. However, let me ask you again to
double-check:
> Under the assumption that this is a branch from an existing file (no new code,
> only some chunks of code deleted), should I use the old or new copyright year?

It's not a big deal either way. I usually just look in Rietveld and see if it
marks the file as A or A+.

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia.cc
File base/time/time_fuchsia.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:17: const mx_time_t usec_since_unix_epoch =
On 2017/05/18 02:52:38, miu wrote:
> On 2017/05/17 08:34:17, Lei Zhang wrote:
> > What is mx_time_t underneath? Can we get away with making this int64_t to
> avoid
> > the static_casts?
> 
> Good point. I had looked into that, and it's uint64_t.
> 
> I am being very pedantic about where the unsigned math is being done versus
the
> signed math because it scares me to depend on the subtle implicit conversion
> rules of the C++ language. ;-) (It has bitten me before!) For example, OTOH, I
> don't know what gets implicitly converted when an unsigned 64-bit int is
divided
> by a signed 64-bit int. The numerator? The denominator? Also, is the result of
> the expression an unsigned or signed type?

Ya, I can't remember all the rules off the top of my head either. Let's back up
our assumptions with tests.

BTW, do you want to add a helper function, since we do the same divison by
|kNanosecondsPerMicrosecond| + casts in 4 different places?

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_mac.cc
File base/time/time_mac.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_mac.cc#n...
base/time/time_mac.cc:214: kTimeTToMicrosecondsOffset -
On 2017/05/18 02:52:38, miu wrote:
> Note: Trybot unit tests caught my erroneous replacement here. Fixed in next
> patchset.

Horray for tests!

[miu, 2017-05-18 20:39:04]

Thanks everyone. All set to commit.

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia.cc
File base/time/time_fuchsia.cc (right):

https://codereview.chromium.org/2891583002/diff/40001/base/time/time_fuchsia....
base/time/time_fuchsia.cc:17: const mx_time_t usec_since_unix_epoch =
On 2017/05/18 19:06:12, Lei Zhang wrote:
> On 2017/05/18 02:52:38, miu wrote:
> > On 2017/05/17 08:34:17, Lei Zhang wrote:
> > > What is mx_time_t underneath? Can we get away with making this int64_t to
> > avoid
> > > the static_casts?
> > 
> > Good point. I had looked into that, and it's uint64_t.
> > 
> > I am being very pedantic about where the unsigned math is being done versus
> the
> > signed math because it scares me to depend on the subtle implicit conversion
> > rules of the C++ language. ;-) (It has bitten me before!) For example, OTOH,
I
> > don't know what gets implicitly converted when an unsigned 64-bit int is
> divided
> > by a signed 64-bit int. The numerator? The denominator? Also, is the result
of
> > the expression an unsigned or signed type?
> 
> Ya, I can't remember all the rules off the top of my head either. Let's back
up
> our assumptions with tests.
> 
> BTW, do you want to add a helper function, since we do the same divison by
> |kNanosecondsPerMicrosecond| + casts in 4 different places?

Done.

[miu, 2017-05-18 20:40:31]

The CQ bit was checked by miu@chromium.org

[miu, 2017-05-18 20:40:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
dsinclair@chromium.org, thestig@chromium.org, pasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2891583002/#ps100001
(title: "REBASE before commit.")

[commit-bot: I haz the power, 2017-05-18 20:41:34]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-19 02:10:14]

CQ is committing da patch.

Bot data: {"patchset_id": 100001, "attempt_start_ts": 1495140031484270,
"parent_rev": "9f0d5e6a0694f57b9a0df2c0336f506bcf5de9e1", "commit_rev":
"eb6e744f08cc8087eb7836753d98d599c28a80f7"}

[commit-bot: I haz the power, 2017-05-19 02:10:28]

Description was changed from

==========
Fuchsia port of base/time, with some refactoring of POSIX time modules.

Uses Magenta's mx_time_get() system call to implement base::Time::Now(),
base::TimeTicks::Now(), and base::ThreadTicks::Now(). All other time
implementation uses the POSIX-compatible API.

As part of this change, it became necessary to do a little clean-up and
fork time_posix.cc into three separate files: time_conversion_posix.cc,
time_exploded_posix.cc, and time_now_posix.cc. The code in these files
was not modified, sans some #ifdef's that were no longer necessary (and
some `git cl format` indentation changes).

Then, the BUILD file includes only the needed implementation files for
each platform:

1. Fuchsia: time_fuchsia.cc, time_conversion_posix.cc and
time_exploded_posix.cc.

2. Mac/IOS: time_mac.cc and time_conversion_posix.cc.

3. All other POSIX platforms (such as CrOS, Android, and Linux): The
three time_*_posix.cc files.

Testing notes: Since base_unittests doesn't compile yet, I could only
confirm that the base/time/* code changes compile on Fuchsia. That said,
base_unittests compiles and runs successfully on all other platforms.

BUG=706592
==========

to

==========
Fuchsia port of base/time, with some refactoring of POSIX time modules.

Uses Magenta's mx_time_get() system call to implement base::Time::Now(),
base::TimeTicks::Now(), and base::ThreadTicks::Now(). All other time
implementation uses the POSIX-compatible API.

As part of this change, it became necessary to do a little clean-up and
fork time_posix.cc into three separate files: time_conversion_posix.cc,
time_exploded_posix.cc, and time_now_posix.cc. The code in these files
was not modified, sans some #ifdef's that were no longer necessary (and
some `git cl format` indentation changes).

Then, the BUILD file includes only the needed implementation files for
each platform:

1. Fuchsia: time_fuchsia.cc, time_conversion_posix.cc and
time_exploded_posix.cc.

2. Mac/IOS: time_mac.cc and time_conversion_posix.cc.

3. All other POSIX platforms (such as CrOS, Android, and Linux): The
three time_*_posix.cc files.

Testing notes: Since base_unittests doesn't compile yet, I could only
confirm that the base/time/* code changes compile on Fuchsia. That said,
base_unittests compiles and runs successfully on all other platforms.

BUG=706592

Review-Url: https://codereview.chromium.org/2891583002
Cr-Commit-Position: refs/heads/master@{#473032}
Committed:
https://chromium.googlesource.com/chromium/src/+/eb6e744f08cc8087eb7836753d98...
==========

[commit-bot: I haz the power, 2017-05-19 02:10:30]

Committed patchset #4 (id:100001) as
https://chromium.googlesource.com/chromium/src/+/eb6e744f08cc8087eb7836753d98...