Time tests fail; timezone parsing bug?

[bradfitz]

GOARCH=386; Debian Lenny

$ hg identify
be829e70975f tip

changeset:   7809:be829e70975f
tag:         tip
user:        Yasuhiro Matsumoto <mattn.jp@gmail.com>
date:        Fri Mar 18 09:28:23 2011 -0700
summary:     godoc: No need to use filepath.IsAbs()

$ ./all.bash 
...
...
make[2]: Leaving directory `/home/bradfitz/go/src/pkg/time'
--- FAIL: time_test.TestSecondsToLocalTime (0.0 seconds)
        SecondsToLocalTime(0):
          want={Year:1969 Month:12 Day:31 Hour:16 Minute:0 Second:0 Weekday:3 ZoneOffset:-28800 Zone:PST}
          have={Year:1970 Month:1 Day:1 Hour:0 Minute:0 Second:0 Weekday:4 ZoneOffset:0 Zone:UTC}
        SecondsToLocalTime(1221681866):
          want={Year:2008 Month:9 Day:17 Hour:13 Minute:4 Second:26 Weekday:3 ZoneOffset:-25200 Zone:PDT}
          have={Year:2008 Month:9 Day:17 Hour:20 Minute:4 Second:26 Weekday:3 ZoneOffset:0 Zone:UTC}
--- FAIL: time_test.TestFormat (0.0 seconds)
        ANSIC expected "Thu Feb  4 21:00:57 2010" got "Fri Feb  5 05:00:57 2010"
        UnixDate expected "Thu Feb  4 21:00:57 PST 2010" got "Fri Feb  5 05:00:57 UTC 2010"
        RubyDate expected "Thu Feb 04 21:00:57 -0800 2010" got "Fri Feb 05 05:00:57 +0000 2010"
        RFC822 expected "04 Feb 10 2100 PST" got "05 Feb 10 0500 UTC"
        RFC850 expected "Thursday, 04-Feb-10 21:00:57 PST" got "Friday, 05-Feb-10 05:00:57 UTC"
        RFC1123 expected "Thu, 04 Feb 2010 21:00:57 PST" got "Fri, 05 Feb 2010 05:00:57 UTC"
        RFC3339 expected "2010-02-04T21:00:57-08:00" got "2010-02-05T05:00:57Z"
        Kitchen expected "9:00PM" got "5:00AM"
        am/pm expected "9pm" got "5am"
        AM/PM expected "9PM" got "5AM"
--- FAIL: time_test.TestParse (0.0 seconds)
        UnixDate: bad tz offset: 0 not -28800
        RFC850: bad tz offset: 0 not -28800
        RFC1123: bad tz offset: 0 not -28800
FAIL
make[1]: *** [test] Error 1
make[1]: Leaving directory `/home/bradfitz/go/src/pkg/time'
make: *** [time.test] Error 2

$ date  
Fri Mar 18 17:58:51 UTC 2011

[robpike]

Comment 1:

I notice that date says UTC.   That's probably relevant, although the time tests should
obviously be independent.  Is this reproducible?

Owner changed to @robpike.

Status changed to WaitingForReply.

[bradfitz]

Comment 2:

Yes, the 386 machine in question is a server in UTC and no /etc/localtime file.
I tried to reproduce on my amd64 desktop (by temporarily renaming my PSTPDT
/etc/localtime away) but that didn't trigger it the bug in a subsequent gotest in the
pkg/time directory.

[peterGo]

Comment 3:

It's likely that the test is complaining that you have neither the
"/usr/share/zoneinfo/America/Los_Angeles" file nor the
"/usr/share/lib/zoneinfo/America/Los_Angeles" file on your server.

[bradfitz]

Comment 4:

Yup, apparently I don't have tzdata on that machine at all:
$ ls -l /usr/share/zoneinfo
ls: cannot access /usr/share/zoneinfo: No such file or directory
$ dpkg -s tsdata
Package `tsdata' is not installed and no info is available.

[robpike]

Comment 5:

What would you like done?  There could be protection in the makefile or protection in
the tests.  I'm in favor of option 3, which is to do nothing, because the purpose of the
tests is to see if your time code will run, and on this system it won't.

[bradfitz]

Comment 6:

How about failing with a more helpful error message at least?
Much of the time package will still work without zoneinfo files.  It just silently
defaults to UTC in the case of no zoneinfo files.  In zoneinfo_unix.go's setupZone():
    case len(tz) > 0:
                var ok bool
                zones, ok = readinfofile(zoneDir + tz)
        if !ok {
                        zones, _ = readinfofile(zoneDir2 + tz)
                }
    case len(tz) == 0:
            // do nothing: use UTC
If that's going to be the behavior (silent fallback instead of, say, a panic) then we
could have an exported func/var in package time for whether or not zoneinfo is loaded. 
Then the tests could either skip those tests or fail loudly with a useful error message.

[peterGo]

Comment 7:

We should at least explain what the actual problem is. For example,
diff --git a/src/pkg/time/time_test.go b/src/pkg/time/time_test.go
--- a/src/pkg/time/time_test.go
+++ b/src/pkg/time/time_test.go
@@ -19,6 +19,12 @@
    os.Setenv("TZ", "America/Los_Angeles")
 }

+func TestZoneData(t *testing.T) {
+   if tz := LocalTime().Zone; tz != "PST" && tz != "PDT" {
+       t.Errorf("Unable to find US Pacific time zone data for testing")
+   }
+}
+
 type TimeTest struct {
    seconds int64
    golden  Time
Which outputs:
--- FAIL: time_test.TestZoneData (0.0 seconds)
    Unable to find US Pacific time zone data for testing
--- FAIL: time_test.TestSecondsToLocalTime (0.0 seconds)
    SecondsToLocalTime(0):
      want={Year:1969 Month:12 Day:31 Hour:16 Minute:0 Second:0 Weekday:3 ZoneOffset:-28800 Zone:PST}
      have={Year:1970 Month:1 Day:1 Hour:0 Minute:0 Second:0 Weekday:4 ZoneOffset:0 Zone:UTC}
    SecondsToLocalTime(1221681866):
      want={Year:2008 Month:9 Day:17 Hour:13 Minute:4 Second:26 Weekday:3 ZoneOffset:-25200 Zone:PDT}
      have={Year:2008 Month:9 Day:17 Hour:20 Minute:4 Second:26 Weekday:3 ZoneOffset:0 Zone:UTC}
--- FAIL: time_test.TestFormat (0.0 seconds)
    ANSIC expected "Thu Feb  4 21:00:57 2010" got "Fri Feb  5 05:00:57 2010"
    UnixDate expected "Thu Feb  4 21:00:57 PST 2010" got "Fri Feb  5 05:00:57 UTC 2010"
    RubyDate expected "Thu Feb 04 21:00:57 -0800 2010" got "Fri Feb 05 05:00:57 +0000 2010"
    RFC822 expected "04 Feb 10 2100 PST" got "05 Feb 10 0500 UTC"
    RFC850 expected "Thursday, 04-Feb-10 21:00:57 PST" got "Friday, 05-Feb-10 05:00:57 UTC"
    RFC1123 expected "Thu, 04 Feb 2010 21:00:57 PST" got "Fri, 05 Feb 2010 05:00:57 UTC"
    RFC3339 expected "2010-02-04T21:00:57-08:00" got "2010-02-05T05:00:57Z"
    Kitchen expected "9:00PM" got "5:00AM"
    am/pm expected "9pm" got "5am"
    AM/PM expected "9PM" got "5AM"
--- FAIL: time_test.TestParse (0.0 seconds)
    UnixDate: bad tz offset: 0 not -28800
    RFC850: bad tz offset: 0 not -28800
    RFC1123: bad tz offset: 0 not -28800
FAIL

[bradfitz]

Comment 8:

LGTM

[robpike]

Comment 9:

This issue was closed by revision 45aeca47278d6188e72d8d633b27865108c27c4.

Status changed to Fixed.