can't handle column type 'timestamp without time zone' correctly

[lib]

can't handle column type 'timestamp without time zone' correctly

[fdr]

It seems like you've done 99% of the work for a test case, can you be so very kind as to recast this as one? I'd really appreciate it. It probably belongs in encode_test.go.

[fdr]

So this blows up in interesting ways:

func TestOneRow(t *testing.T) {
    db := openTestConn(t)
    defer db.Close()

    r, err := db.Query("SELECT '2000-01-01T00:00:00'::timestamp")
    if err != nil {
        t.Fatalf("Could not run query: ", err)
    }

    rowCount := 0
    for r.Next() {
        rowCount += 1
    }

    if rowCount != 1 {
        t.Fatalf("Expected exactly one row, but got %v", rowCount)
    }
}

Yielding

encode_test.go:107:     Expected exactly one row, but got 0

Also interesting:

func TestTimestampWithOutTimezone(t *testing.T) {
    db := openTestConn(t)
    defer db.Close()

    r, err := db.Query("SELECT '2000-01-01T00:00:00'::timestamp")
    if err != nil {
        t.Fatalf("Could not run query: ", err)
    }

    n := r.Next()

    // Elided to continue the test and see something interesting.
    //
    // if n != true {
    //  t.Fatal("Expected at least one row")
    // }

    var result time.Time
    err = r.Scan(&result)
    if err != nil {
        t.Fatalf("Did not expect error scanning row: %v", err)
    }

    expected, err := time.Parse(time.RFC3339, "2000-01-01T00:00:00Z")
    if err != nil {
        t.Fatalf("Could not parse test time literal: %v", err)
    }

    if !result.Equal(expected) {
        t.Fatalf("Expected time to match %v: got mismatch %v",
            expected, result)
    }

    n = r.Next()
    if n != false {
        t.Fatal("Expected only one row")
    }
}

In the above, r.Next() is broken, but we avoid checking it for the sake of experimentation. Continuing the test results in:

encode_test.go:131:     Did not expect error scanning row: pq: decode: parsing time "2000-01-01 00:00:00" as "2006-01-02 15:04:05:00": cannot parse "" as ":00"

To make things slightly worse, it doesn't seem that Go has a very good notion of "no known location" for its time type. Although such unadorned timestamps make me unhappy in general, the fact is they are out there, and it seems that the Go standard library has ignored their existence. The most obvious ugly thing to do is to pretend that such timestamps have come from UTC, even though that's an overconfident lie. I have not ascertained if there is a better "pseudo-location" that just means "I have no idea what the timezone is", nor do I see a good way to define one in the Go time package.

I may have to convert Postgres timestamp to a string and leave it to the user, for the most pedantic of all interpretations, and hope people just switch to timestamptz (they should) instead.

[fdr]

I think a fix for this is in 7f1933f.

The error reporting seems pretty weird when decode has an error, but I think this should help you. If not, reopen.

[datastream]

old style '2013-01-04 20:14:58.80033' broken now. It imports new bug.

[fdr]

Reverted. 2224d83

It regresses on go 1.0.2; on the 'devel' version it seems to work. What it does on 1.0.3 is yet unknown to me.

[fdr]

I have committed a new version, 284a1d4.

This time, I have tested it on Go 1.0.2 on Ubuntu Quantal and Go 1.0.3 on my Macintosh, and whereas the old patch causes a regression in the 1.0.2 copy, this version does not.