Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
datastream opened this issue Jan 4, 2013 · 6 comments
Closed

Comments

@datastream
Copy link

id | name | server_id | created_at | updated_at
------+---------------------+-----------+---------------------------+---------------------------
1501 | test | 0 | 2013-01-04 20:14:58.80033 | 2013-01-04 20:14:58.80033
(1 row)

r, e := db.Query("SELECT name FROM hosts WHERE name='test'")
r.Next() retrue true


id | name | server_id | created_at | updated_at
------+---------------------+-----------+---------------------------+---------------------------
1501 | test | 0 | 2013-01-04 20:14:58 | 2013-01-04 20:14:58.80033
(1 row)

r, e := db.Query("SELECT name FROM hosts WHERE name='test'")
r.Next() retrue false

@fdr
Copy link
Member

fdr commented Jan 4, 2013

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
Copy link
Member

fdr commented Jan 5, 2013

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
Copy link
Member

fdr commented Jan 5, 2013

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.

@fdr fdr closed this as completed Jan 5, 2013
@datastream
Copy link
Author

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

@fdr
Copy link
Member

fdr commented Jan 5, 2013

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 fdr reopened this Jan 5, 2013
@fdr
Copy link
Member

fdr commented Jan 5, 2013

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.

@fdr fdr closed this as completed Jan 5, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants