re PR go/80302 (FAIL: time on systems with tzdata2017b installed)

	PR go/80302
    time: make the ParseInLocation test more robust

    This is a backport of https://golang.org/cl/37964 from the gc toolchain.

    Original description:

        The tzdata 2017a update (2017-02-28) changed the abbreviation of the
        Asia/Baghdad time zone (used in TestParseInLocation) from 'AST' to the
        numeric '+03'.

        Update the test so that it skips the checks if we're using a recent
        tzdata release.

    Updates golang/go#19457
    Fixes GCC PR 80302.

    Reviewed-on: https://go-review.googlesource.com/39470

From-SVN: r246695

diff --git a/libgo/go/time/format_test.go b/libgo/go/time/format_test.go
index 648ead0886c8012b29c189ebaf44b8b35b3d58ba..0e4a417430937e99ab08ee1872c4a5dc8bb2a55a 100644 (file)
--- a/libgo/go/time/format_test.go
+++ b/libgo/go/time/format_test.go
@@ -245,27 +245,45 @@ func TestParseDayOutOfRange(t *testing.T) {
        }
 }
 
+// TestParseInLocation checks that the Parse and ParseInLocation
+// functions do not get confused by the fact that AST (Arabia Standard
+// Time) and AST (Atlantic Standard Time) are different time zones,
+// even though they have the same abbreviation.
+//
+// ICANN has been slowly phasing out invented abbreviation in favor of
+// numeric time zones (for example, the Asia/Baghdad time zone
+// abbreviation got changed from AST to +03 in the 2017a tzdata
+// release); but we still want to make sure that the time package does
+// not get confused on systems with slightly older tzdata packages.
 func TestParseInLocation(t *testing.T) {
-       // Check that Parse (and ParseInLocation) understand that
-       // Feb 01 AST (Arabia Standard Time) and Feb 01 AST (Atlantic Standard Time)
-       // are in different time zones even though both are called AST
 
        baghdad, err := LoadLocation("Asia/Baghdad")
        if err != nil {
                t.Fatal(err)
        }
 
-       t1, err := ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", baghdad)
+       var t1, t2 Time
+
+       t1, err = ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", baghdad)
        if err != nil {
                t.Fatal(err)
        }
-       t2 := Date(2013, February, 1, 00, 00, 00, 0, baghdad)
-       if t1 != t2 {
-               t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad) = %v, want %v", t1, t2)
-       }
+
        _, offset := t1.Zone()
-       if offset != 3*60*60 {
-               t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad).Zone = _, %d, want _, %d", offset, 3*60*60)
+
+       // A zero offset means that ParseInLocation did not recognize the
+       // 'AST' abbreviation as matching the current location (Baghdad,
+       // where we'd expect a +03 hrs offset); likely because we're using
+       // a recent tzdata release (2017a or newer).
+       // If it happens, skip the Baghdad test.
+       if offset != 0 {
+               t2 = Date(2013, February, 1, 00, 00, 00, 0, baghdad)
+               if t1 != t2 {
+                       t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad) = %v, want %v", t1, t2)
+               }
+               if offset != 3*60*60 {
+                       t.Fatalf("ParseInLocation(Feb 01 2013 AST, Baghdad).Zone = _, %d, want _, %d", offset, 3*60*60)
+               }
        }
 
        blancSablon, err := LoadLocation("America/Blanc-Sablon")
@@ -273,6 +291,9 @@ func TestParseInLocation(t *testing.T) {
                t.Fatal(err)
        }
 
+       // In this case 'AST' means 'Atlantic Standard Time', and we
+       // expect the abbreviation to correctly match the american
+       // location.
        t1, err = ParseInLocation("Jan 02 2006 MST", "Feb 01 2013 AST", blancSablon)
        if err != nil {
                t.Fatal(err)