Reland http://codereview.chromium.org/4139008, with a different

Reland http://codereview.chromium.org/4139008, with a different
approach to creating version numbers. The old one had troubles
with timezones. This one is simpler and better.

BUG=49233
TEST=Covered by unit tests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=66582

[Erik does not do reviews, 2010-11-04 20:41:22]

http://codereview.chromium.org/4471001/diff/1/3
File chrome/browser/extensions/convert_web_app.cc (right):

http://codereview.chromium.org/4471001/diff/1/3#newcode63
chrome/browser/extensions/convert_web_app.cc:63: double millis = (create_time -
create_time.LocalMidnight()).InMilliseconds();
I'm pretty sure this won't be affected by daylight savings time switches, but
let me talk it out so you can verify.
- within a single day, LocalMidnight should always be the same number,
regardless of DST changes
- create_time internally is UTC so it can never move backwards, even across DST
changes
- therefore, at any time millis will always increase and never go backwards

It does seem like it's possible for it to get hosed by time zone changes though.
 If I move across timezones, then it's possible for LocalMidnight to increase
within a single day, which could cause millis to move backwards.  If you did the
whole thing in UTC using a UTC midnight (it doesn't look like this exists right
now), then I think this would go away.

WDYT?

[Aaron Boodman, 2010-11-04 21:52:45]

On 2010/11/04 20:41:22, Erik Kay wrote:
> http://codereview.chromium.org/4471001/diff/1/3
> File chrome/browser/extensions/convert_web_app.cc (right):
> 
> http://codereview.chromium.org/4471001/diff/1/3#newcode63
> chrome/browser/extensions/convert_web_app.cc:63: double millis = (create_time
-
> create_time.LocalMidnight()).InMilliseconds();
> I'm pretty sure this won't be affected by daylight savings time switches, but
> let me talk it out so you can verify.
> - within a single day, LocalMidnight should always be the same number,
> regardless of DST changes
> - create_time internally is UTC so it can never move backwards, even across
DST
> changes
> - therefore, at any time millis will always increase and never go backwards
> 
> It does seem like it's possible for it to get hosed by time zone changes
though.
>  If I move across timezones, then it's possible for LocalMidnight to increase
> within a single day, which could cause millis to move backwards.  If you did
the
> whole thing in UTC using a UTC midnight (it doesn't look like this exists
right
> now), then I think this would go away.
> 
> WDYT?

Thanks for pointing this out. I was originally trying to do everything in local
for clarity. I wasn't that worried about time moving backward since we'll be
overinstalling each time. But I see now that this function assumes the caller
correctly created the passed in Time object wrt time zones. I will look at doing
it all in UTC to simplify.

[Aaron Boodman, 2010-11-05 00:28:33]

Ok, ready for another look.

[Erik does not do reviews, 2010-11-05 14:50:04]

LGTM

[Aaron Boodman, 2010-11-07 17:03:37]

+jrg for mac changes

This turned up a bug in base::Time on mac. I am not sure if my fix is the best
fix, but it seems to work.

[John Grabowski, 2010-11-08 22:50:24]

Mac change LGTM

+cc mento since CFGregorianDateGetAbsoluteTime is also used in
message_pump_mac.mm

http://codereview.chromium.org/4471001/diff/25001/26001
File base/time_mac.cc (right):

http://codereview.chromium.org/4471001/diff/25001/26001#newcode80
base/time_mac.cc:80: // CFGregorianDateGetAbsoluteTime deals only in second
resolution.
Perhaps you can put the warning above the call to CFGregorianDateGetAbsoluteTime