OpenE2K
/
gcc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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
This commit is contained in:
Ian Lance Taylor 2017-04-04 19:37:22 +00:00
parent e1201dff2f
commit cf26173d18
1 changed files with 31 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
libgo/go/time/format_test.go
View File

@ -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)