Fix the incorrectly named time points in VisitDatabaseTest.GetHistoryCount.

components/history/core/browser/visit_database_unittest.cc

Index: components/history/core/browser/visit_database_unittest.cc
diff --git a/components/history/core/browser/visit_database_unittest.cc b/components/history/core/browser/visit_database_unittest.cc
index 8074dd92c0ddf6315cc88381b825e337d81bfe8b..c1b14bf36bfcf0c68fd680d32db488b4141488f5 100644
--- a/components/history/core/browser/visit_database_unittest.cc
+++ b/components/history/core/browser/visit_database_unittest.cc
@@ -425,8 +425,8 @@ TEST_F(VisitDatabaseTest, GetHistoryCount) {
   // round down to the beginning of the day in the local time, taking timezones
   // and DST into account. This is necessary to achieve the same equivalence
   // class on days as the DATE(..., 'localtime') function in SQL.
-  Time yesterday = (today - TimeDelta::FromHours(36)).LocalMidnight();
-  Time two_days_ago = (yesterday - TimeDelta::FromHours(36)).LocalMidnight();
+  Time yesterday = (today - TimeDelta::FromSeconds(1)).LocalMidnight();

[sdefresne, 2015/10/06 17:14:32]

Will this work around day light saving change? Why not do "today -
TimeDelta::FromHours(3)" (with the assumption that daylight time saving is at
most one hour change, using a delta of 3 hours should always be yesterday)? 

[lwchkg, 2015/10/07 04:59:37]

Thanks for a good point. DST is simply very hard and confusing indeed. Just had
a look of http://www.timeanddate.com/time/change/brazil/brasilia , and it
reveals that there is NO 18/Oct/2015 MIDNIGHT IN Brazil!

BTW, if the LocalMidnight (if exists) is found correctly, turning back one
second should be enough in both forward and backward shift.
(msramek, is it possible to do the unit test in Brazil time in your computer?)

(Sadly it also means today.LocalMidnight() !=
today.LocalMidnight().LocalMidnight() is possible. I'll try to produce this
stunning result.)

Anyway, looks like we need to audit all implementations using LocalMidnight for
correctness (for both Chromium and SQLite code).

[sdefresne, 2015/10/07 07:42:54]

Or you could fix that initial date instead of using time::Now().

[sdefresne, 2015/10/07 13:55:36]

I was thinking of using a date known not to cause any issue (something like
2015-07-07). I guess the code is no worse now than it is without the patch, and
the name are more correct with this CL, so lgtm.

[msramek, 2015/10/13 18:10:05]

Ok, I fixed the date in the middle of the summer to avoid trouble, and thus also
moved the comment of DST down to the section that actually uses it.

I tried to run this unittest in the Brazil timezone, and it failed. Not just in
the DST section, but right at the first EXPECT_EQ. As far as I understand, this
is because in our case, LocalMidnight() returns the first valid time in the day
(which could be 1am in Brazil), but in SQL it behaves differently. This is a
problem that should be solved at an entirely different layer; I'll bring
attention to it, but I won't attempt to solve it in this CL.

+  Time two_days_ago = (yesterday - TimeDelta::FromSeconds(1)).LocalMidnight();
   Time now = two_days_ago;
 
   ui::PageTransition standard_transition = ui::PageTransitionFromInt(