Retry date comparison to avoid a rare flake that might be associated with DST

pkg/intl/test/date_time_format_test_core.dart

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 /**
  * Tests the DateFormat library in dart. This file contains core tests that
  * are run regardless of where the locale data is found, so it doesn't expect to
  * be run on its own, but rather to be imported and run from another test file.
  */
 
@@ skipping 145 matching lines @@
       DateFormat.MONTH_WEEKDAY_DAY,
       DateFormat.NUM_MONTH_WEEKDAY_DAY,
       DateFormat.ABBR_MONTH_WEEKDAY_DAY];
   for(int i = 0; i < formatsToTest.length; i++) {
     var skeleton = formatsToTest[i];
     if (!badSkeletons.any((x) => x == skeleton)) {
       var format = new DateFormat(skeleton, localeName);
       var actualResult = format.format(date);
       var parsed = format.parse(actualResult);
       var thenPrintAgain = format.format(parsed);
+      // Very rarely, it seems like we can get an off-by-one error when using a
+      // format that only prints the date. This seems like it might be
+      // associated with a daylight savings transition, but it's not at all
+      // clear how. Regardless, if we get a non-equal result once, re-parse
+      // and re-print in case it's transient.
+      if (thenPrintAgain != actualResult) {
+        parsed = format.parse(actualResult);
+        thenPrintAgain = format.format(parsed);
+      }

[kustermann, 2013/11/28 10:16:26]

I don't think you should do this.

Now that I see the code for the test, I think it should be 100% deterministic.
There should be no reason why this should be flaky.

I looked a bit deeper, and the only effect that the
format.parse()/format.format() calls have is calling two native functions:

 15   static int _timeZoneOffsetInSecondsForClampedSeconds(int
secondsSinceEpoch)
 16       native "DateNatives_timeZoneOffsetInSeconds";
 17 
 18   static int _localTimeZoneAdjustmentInSeconds()
 19       native "DateNatives_localTimeZoneAdjustmentInSeconds";

The only possibility is that the timezone on the buildbot VM changed, which is
*very unlikely*.

If that happens again, we'd like to get more information: Maybe you could print
information in case the check fails (such as local timezone, .....)

[floitsch, 2013/11/28 10:29:05]

I agree with Martin. This should never happen, and if it does again we want to
know why and how.
Instead of expect(thenPrintAgain, equals(actualResult)), do an if before:
if (thenPrintAgain != actualResult) {
  print(date);
  print(date.millisecondsSinceEpoch);
  print(date.timeZoneOffset);
  print(date);
  print(parsed.millisecondsSinceEpoch);
  print(parsed.timeZoneOffset);
  print(parsed.timeZone);
  print(parsed.timeZone);
  print(new DateTime.now().millisecondsSinceEpoch);
  // and any other information that could be helpful to debug.
}

       expect(thenPrintAgain, equals(actualResult));
     }
   }
 }
 
 /** A shortcut for returning all the locales we have available.*/
 List<String> allLocales() => DateFormat.allLocalesWithSymbols();
 
 Function _subsetFunc;
 
@@ skipping 219 matching lines @@
     var f = new DateFormat("D");
     var dates = generateDates(2012, 1);
     var nonLeapDates = generateDates(2013, 0);
     verifyOrdinals(dates);
     verifyOrdinals(nonLeapDates);
     // Check one hard-coded just to be on the safe side.
     var aDate = new DateTime(2012, 4, 27, 13, 58, 59, 012);
     expect(f.format(aDate), "118");
   });
 }