Log the freshness of the Variations seed in a histogram.

chrome/browser/metrics/variations/variations_service.cc

Index: chrome/browser/metrics/variations/variations_service.cc
diff --git a/chrome/browser/metrics/variations/variations_service.cc b/chrome/browser/metrics/variations/variations_service.cc
index 00c7816705d3638bc190824bbf3f7101bc93150f..6807d3d3127056ac5993c59d873929bd16e3786a 100644
--- a/chrome/browser/metrics/variations/variations_service.cc
+++ b/chrome/browser/metrics/variations/variations_service.cc
@@ -215,6 +215,7 @@ void VariationsService::RegisterPrefs(PrefRegistrySimple* registry) {
   registry->RegisterStringPref(prefs::kVariationsSeed, std::string());
   registry->RegisterInt64Pref(prefs::kVariationsSeedDate,
                               base::Time().ToInternalValue());
+  registry->RegisterInt64Pref(prefs::kVariationsLastFetchTime, 0);
 }
 
 // static
@@ -288,6 +289,25 @@ void VariationsService::OnURLFetchComplete(const net::URLFetcher* source) {
           base::TimeDelta::FromMilliseconds(kServerTimeResolutionMs),
           latency);
     }
+
+    // If this is not the first successful fetch, record the delta between now
+    // and the last successful fetch.
+    int64 internal_now = base::Time::Now().ToInternalValue();
+    int64 last_fetch_time =
+        local_state_->GetInt64(prefs::kVariationsLastFetchTime);
+    if (last_fetch_time) {
+      int64 internal_delta = internal_now - last_fetch_time;
+      DCHECK_GE(internal_delta, 0);
+      base::TimeDelta delta =
+          base::TimeDelta::FromInternalValue(internal_delta);
+      // Note that 10000 is approximately 7 days.
+      UMA_HISTOGRAM_COUNTS_10000("Variations.SeedFreshness",

[Ilya Sherman, 2013/02/22 00:31:28]

You sure you don't want UMA_HISTOGRAM_CUSTOM_TIMES?

[SteveT, 2013/02/22 00:38:37]

Hmm, it's a little hard to parse what UMA_HISTOGRAM_CUSTOM_TIMES does from
histograms.h.

What's the time unit that it takes? Some uses of it suggest it takes the raw
unit of TimeDelta (which is something super granular like microseconds or
something?).

[Ilya Sherman, 2013/02/22 00:45:50]

You give it bounds for the highest granularity of time that you care about (e.g.
half an hour) and the lowest granularity (e.g. 7 days), and the number of
buckets to use in the histogram.  Then you pass in a TimeDelta object as the
sample, and it does the conversion for you.  So, it's essentially equivalent to
UMA_HISTOGRAM_CUSTOM_COUNTS, except that it will do consistent time conversions
for you.

[SteveT, 2013/02/22 01:01:02]

So in my latest patch, I used UMA_HISTOGRAM_CUSTOM_TIMES as you suggested (with
highest granularity = 1 minute, lowest = 7 days). Now I'm guessing crazy big
values that I don't understand. Are they in TimeDelta raw units? Does the
dashboard make them more readable in any way (ie - provide units in the UI)?

[Ilya Sherman, 2013/02/22 01:12:07]

Oh, I see what you mean.  You're right, the units on the dashboard would end up
in milliseconds, which could be hard to read.  Sounds like a nice feature
improvement to the dashboard; but for now I guess I'd recommend something like
the following:

UMA_HISTOGRAM_CUSTOM_COUNTS(
    "Variations.SeedFreshness", 1, TimeDelta::FromDays(7).InMinutes(), 50,
    delta.InMinutes());

But, if you think COUNTS_10000 is clearer, that's ok too.  Sorry for the
misdirection!

[SteveT, 2013/02/22 01:26:41]

Yeah, if the dashboard had a way to select the time units for TIME histograms,
this would be fine. But since we're dealing with potentially long periods, doing
the units in minutes is way easier to read, methinks.

I like your compromise. Easier to understand than _10000.

+                                 delta.InMinutes());
+    }
+
+    // Record the time of the most recent successful fetch.
+    local_state_->SetInt64(prefs::kVariationsLastFetchTime,
+                           internal_now);
   }
 
   if (response_code != net::HTTP_OK) {