@lavalamp

Tests fail with a roundtrip error around parsing time. I know you changed that in upstream gofuzz..

--- FAIL: TestRoundTripTypes (5.11s)
serialization_test.go:64: 0: Node: error unmarshaling JSON: parsing time "-136438948280-12-03T08:04:46-08:00" as "2006-01-02T15:04:05Z07:00": cannot parse "-136438948280-12-03T08:04:46-08:00" as "2006"

Ah the default fuzz function can generate negative times, which don't roundtrip.

Huh, can't decide if this is a bug in time.Unix (which accepts values that produce an invalid time), if fuzz's time function should be changed, or if we should just add a Fuzz() function to util.Time.

This is what fuzz.Interface is for, I guess...

On Tue, Mar 3, 2015 at 9:55 AM, Daniel Smith notifications@github.com
wrote:

Ah the default fuzz function can generate negative times, which don't
roundtrip.

Huh, can't decide if this is a bug in time.Unix (which accepts values that
produce an invalid time), if fuzz's time function should be changed, or if
we should just add a Fuzz() function to util.Time.

—
Reply to this email directly or view it on GitHub
#4985 (comment)
.

And why don't negative times roundtrip? That seems valid.

On Tue, Mar 3, 2015 at 12:22 PM, Tim Hockin thockin@google.com wrote:

This is what fuzz.Interface is for, I guess...

On Tue, Mar 3, 2015 at 9:55 AM, Daniel Smith notifications@github.com
wrote:

Ah the default fuzz function can generate negative times, which don't
roundtrip.

Huh, can't decide if this is a bug in time.Unix (which accepts values
that produce an invalid time), if fuzz's time function should be changed,
or if we should just add a Fuzz() function to util.Time.

—
Reply to this email directly or view it on GitHub
#4985 (comment)
.

time.Time internal constraints are getting violated: http://golang.org/src/time/time.go?s=1855:2369#L29

Updated with latest gofuzz which handles time.Time more correctly.

Travis disagrees... our time format doesn't marshal nanoseconds. We'll have to write a custom Fuzz() on util.Time().

wierd, it passes locally

On Thu, Mar 5, 2015 at 10:39 AM, Daniel Smith notifications@github.com
wrote:

Travis disagrees... our time format doesn't marshal nanoseconds. We'll
have to write a custom Fuzz() on util.Time().

—
Reply to this email directly or view it on GitHub
#4985 (comment)
.

I can not fathom how this passes 100% locally but fails on travis

Should pass Travis now

For anyone watching, semantic deep equal was saying that uncomparable private fields were assumed equal, which let it pass on my machine. But on Travis, something about timezones caused it to fail, exposing the time semantic-equal issue. Now we fuzz to leave off nanosecond and semantic compare in UTC always.

rebased now

LGTM