ParseTimestamp will not parse input from FormatTimestamp

[samuelkaufman]

Hi,
I just submitted https://github.com/lib/pq/pull/605/files.
Basically I expected ParseTimestamp to be able to parse what FormatTimestamp produces, but it errors instead. I didn't have the time/skill offhand to see what the error is actually referring to but I committed a failing test case.

Use case here is I've got a row with an expire date that can be infinity, as I kind of felt a zero value would be the wrong abstraction, being that you'd expect setting a date to 1970 would mean it is expired, not that it never expires.

So I am manually calling Format and Parse rather than letting lib/pq do its thing, which led me to this issue.

[johto]

Use case here is I've got a row with an expire date that can be infinity, as I kind of felt a zero value would be the wrong abstraction, being that you'd expect setting a date to 1970 would mean it is expired, not that it never expires.

Have you looked at the (hacky) support for infinite timestamps?

[samuelkaufman]

I had looked at it, but I figured it was easier/cleaner to call encode and decode manually vs calling that global function, defining global maxes and mins and comparing values to those.

[samuelkaufman]

FWIW I gave up for now and am using the EnableInfiniteTs function, so no immediate urgency on my part :)

[bartgrantham]

I'd like to point out how difficult pq.EnableInfinityTs() is in production code. Since it has to happen before any database connections, that kinda forces it into the init() of any module that uses it. But since it panics if called twice that's a problem when mixing modules. What's worse is that there's no way to ask the driver if this has been set, so a workaround of wrapping the call in a guard if block isn't possible.

I appreciate that this is a mismatch in the ranges supported by PG's timestamp and go's Time types, but I'd suggest that the values of -infinity and infinity are so useful in schema designs that the library should just clamp those values to the minimum and maximum possible Time values by default. Ie. effectively this: pq.EnableInfinityTs(time.Time{}, time.Unix(1<<63-62135596801, 999999999)). (min/max values cribbed from stackoverflow threads)

Is there an explanation for why the driver doesn't handle -infinity/infinity by default without setting this?

[sfllaw]

This also happens when the timestamp has Zulu as the timezone: 2006-01-02 15:04:05.999999999Z

Here is a reproducible test case: (Playground)

package main

import (
	"fmt"
	"time"

	"github.com/lib/pq"
)

func main() {
	now := string(pq.FormatTimestamp(time.Now()))
	fmt.Println("now =", now)

	ts, err := pq.ParseTimestamp(time.UTC, now)
	if err != nil {
		fmt.Println("err =", err)
	} else {
		fmt.Println("ts =", ts)
	}
}

// Output:
// now = 2009-11-10 23:00:00Z
// err = expected end of input, got Z

The error appears to occur because ParseTimestamp doesn’t realize that case-insensitive z can also be a timezone, which should terminate the fractional seconds parsing:

pq/encode.go

Line 419 in d408f9c

fracOff := strings.IndexAny(str[fracStart:], "-+ ")