FromLocalExploded() works like FromExploded() on chromium.mac/ios-simulator |
||||||||||
Issue descriptionbase_unittests (iPad Air 2 iOS 9.0) failing on chromium.mac/ios-simulator Builders failed on ios-simulator: https://build.chromium.org/p/chromium.mac/builders/ios-simulator Recently, these two builds failed: https://uberchromegw.corp.google.com/i/chromium.mac/builders/ios-simulator/builds/23833 https://uberchromegw.corp.google.com/i/chromium.mac/builders/ios-simulator/builds/23770 The time differences are oof by up to 5 hours: TimeFormattingTest.TimeFormatDateUS: ../../base/i18n/time_formatting_unittest.cc:211: Failure Expected: ASCIIToUTF16("4/30/11, 3:42:07 PM") Which is: 4/30/11, 3:42:07 PM To be equal to: TimeFormatShortDateAndTime(time) Which is: 4/30/11, 8:42:07 AM ../../base/i18n/time_formatting_unittest.cc:213: Failure Expected: ASCIIToUTF16("4/30/11, 3:42:07 PM ") + GetShortTimeZone(time) Which is: 4/30/11, 3:42:07 PM PDT To be equal to: TimeFormatShortDateAndTimeWithTimeZone(time) Which is: 4/30/11, 8:42:07 AM PDT ../../base/i18n/time_formatting_unittest.cc:218: Failure Expected: ASCIIToUTF16("Saturday, April 30, 2011 at 3:42:07 PM") Which is: Saturday, April 30, 2011 at 3:42:07 PM To be equal to: TimeFormatFriendlyDateAndTime(time) Which is: Saturday, April 30, 2011 at 8:42:07 AM Also, this is already disabled on Android because it doesn't seem to be the first time that this happens: Issue 582915 Issue 671429 I wouldn't really like to disable them on iOS as well to keep at least some coverage.
,
Oct 13 2017
So, the actual timezone is America/Los_Angeles (US PDT), but the hard-coded expectation is 7 hours ahead of it.
kTestDateTimeExploded has 2011-04-30T15:42:07 . So, the issue here is FromLocalExploded does not work as expected. |time| obtained that way is 7 hours behind than intended (when the actual timezone is US PDT). That is, FromLocalExploded behaves like FromExploded.
EXPECT_TRUE(Time::FromLocalExploded(kTestDateTimeExploded, &time));
EXPECT_EQ(ASCIIToUTF16("Apr 30, 2011"), TimeFormatShortDate(time));
EXPECT_EQ(ASCIIToUTF16("4/30/11"), TimeFormatShortDateNumeric(time));
EXPECT_EQ(ASCIIToUTF16("4/30/11, 3:42:07 PM"),
TimeFormatShortDateAndTime(time));
EXPECT_EQ(ASCIIToUTF16("4/30/11, 3:42:07 PM ") + GetShortTimeZone(time),
TimeFormatShortDateAndTimeWithTimeZone(time));
Is this a new failure ?
Adding a few people who touched base/time/time_mac.cc .
,
Oct 13 2017
Maksim, would you have time to investigate this?
,
Oct 13 2017
Note https://chromereviews.googleplex.com/2872065/. That was six years ago. Not sure if it’s still a problem.
,
Oct 13 2017
,
Oct 13 2017
Maksim isn't working on time stuff anymore (And is not a Google employee).
,
Oct 17 2017
For the unit test in question, we can do what's suggested in bug 671429 . However, this bug should be left open to deal with FromLocalExploded().
,
Oct 17 2017
Hi, I would definitely try to find some spare time for this, but not sure when. Working on mus stuff in downstream now. If anybody is going to grab it, please feel free to do so. mmenke, if anything, please use my @igalia account.
,
Oct 18
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 18
Justin seems like you were involved with this before. Does this still need work?
,
Oct 19
I don't think fixing FromExploded/FromLocalExploded is specific to iOS. miu@ can you triage as base/time OWNER? Thanks!
,
Jan 11
This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by fhorschig@chromium.org
, Oct 12 2017