Support time.Time instead of int64 for date fields

[mbroshi-stripe]

Why?

This change supports codegen changes that converts datetime fields from int64 to time.Time as brought up in this issue: #1205.

What?

• The main change is in the form serialization in form.go for time.Time fields. Serialization is performed by reflection, and we do not want the default behavior of inspecting into a time.Time type, rather just convert it to an int64
• While I was in there, I also created convenience method Time, TimeValue, UnixTime and UnixValue to help in creating time.Time and *time.Time parameter fields
• I also updated unit tests expecting an int64 type

See Also

• Parse unix timestamps into times (time.Time) #1205

[jar-stripe]

what happens if this is called with a v other than a time.Time; does this return an error we need to look for, or will val just be Zero (and is that swallowing an error?)

[mbroshi-stripe]

It panics. I think that's OK, but open for other thoughts. It's only called in one location surrounded by

if t == reflect.TypeOf(time.Time{}) {
	return timeEncoder
}

so logically, the type assertion v.Interface().(time.Time) must succeed. I would definitely rather fail fast here rather than silently. The alternative would be to bubble up an error, but it feels a little weird to return an error due to a bug.

[mbroshi-stripe]

In fact, I'm realizing we have the same panic behavior in the rest of type assertions in form.go, so this is really no different than current behavior (where we do a type assertion to an integer:

stripe-go/form/form.go

Line 321 in b384f33

val := v.Int()

[helenye-stripe]

:lurk: I think the merge-base for this PR should be the beta branch!