+void DateFormatRoundTripTest::TestCentury()
+{
+ UErrorCode status = U_ZERO_ERROR;
+ Locale locale("es_PA");
+ UnicodeString pattern = "MM/dd/yy hh:mm:ss a z";
+ SimpleDateFormat fmt(pattern, locale, status);
+ if (U_FAILURE(status)) {
+ dataerrln("Fail: construct SimpleDateFormat: %s", u_errorName(status));
+ return;
+ }
+ UDate date[] = {-55018555891590.05, 0, 0};
+ UnicodeString result[2];
+
+ fmt.format(date[0], result[0]);
+ date[1] = fmt.parse(result[0], status);
+ fmt.format(date[1], result[1]);
+ date[2] = fmt.parse(result[1], status);
+
+ /* This test case worked OK by accident before. date[1] != date[0],
+ * because we use -80/+20 year window for 2-digit year parsing.
+ * (date[0] is in year 1926, date[1] is in year 2026.) result[1] set
+ * by the first format call returns "07/13/26 07:48:28 p.m. PST",
+ * which is correct, because DST was not used in year 1926 in zone
+ * America/Los_Angeles. When this is parsed, date[1] becomes a time
+ * in 2026, which is "07/13/26 08:48:28 p.m. PDT". There was a zone
+ * offset calculation bug that observed DST in 1926, which was resolved.
+ * Before the bug was resolved, result[0] == result[1] was true,
+ * but after the bug fix, the expected result is actually
+ * result[0] != result[1]. -Yoshito
+ */
+ /* TODO: We need to review this code and clarify what we really
+ * want to test here.
+ */
+ //if (date[1] != date[2] || result[0] != result[1]) {
+ if (date[1] != date[2]) {
+ errln("Round trip failure: \"%S\" (%f), \"%S\" (%f)", result[0].getBuffer(), date[1], result[1].getBuffer(), date[2]);
+ }
+}
+