For those that didn't previously use microseconds, we'd need a new pref and a step in browser_prefs.cc::Migrate*Prefs() to migrate.

Not mandatory though.

Ooh interesting. Okay, doesn't look like anyone is actively migrating anything, but looking through history, I'm starting to get an idea. We basically check to see if the old pref is set, and new pref is not set, and then convert/migrate the value, and clear the old pref regardless of other logic. And then ~1 year later we remove the whole section.

The pref that can be migrated is https://cs.chromium.org/chromium/src/components/sync/base/sync_prefs.cc?l=53 , as we'll want to convert from seconds resolution to microseconds resolution.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0ef461ea242fc7b073d9c8acba75738ccffa0066

commit 0ef461ea242fc7b073d9c8acba75738ccffa0066
Author: Sky Malice <skym@google.com>
Date: Tue Jun 19 01:28:21 2018

[NTP Snippets] Switch RemoteSuggestionsSchedulerImpl to Time and TimeDelta pref methods.

Because time_serialization.cc stored Time and DeltaTime in
microseconds, and Time since the windows epoch, which is the exact
same way that PrefService is storing these time fields, this change
should be fully backwards compatible.

Bug: 853755
Change-Id: I22d734d030ca550a654319e37abf6653890c1bdb
Reviewed-on: https://chromium-review.googlesource.com/1104581
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Sky Malice <skym@chromium.org>
Cr-Commit-Position: refs/heads/master@{#568282}
[modify] https://crrev.com/0ef461ea242fc7b073d9c8acba75738ccffa0066/components/ntp_snippets/remote/remote_suggestions_scheduler_impl.cc
[modify] https://crrev.com/0ef461ea242fc7b073d9c8acba75738ccffa0066/components/ntp_snippets/time_serialization.cc
[modify] https://crrev.com/0ef461ea242fc7b073d9c8acba75738ccffa0066/components/ntp_snippets/time_serialization.h
[modify] https://crrev.com/0ef461ea242fc7b073d9c8acba75738ccffa0066/components/ntp_snippets/time_serialization_unittest.cc