Comment 1:

Labels changed: added release-go1.5, repo-main.

On the other hand, the comment for Scan() in your paste says: An error should be returned if the value can not be stored without loss of information. Time.String() throws away quite a lot of information about the time zone and location: http://play.golang.org/p/3QqXgTwwZ1

As mentioned by @johto, there will be loss of information while transforming time.Time to string. I think it is best to remove time.Time from the restricted set of src types Scan(src interface{}) operates on.

Thoughts?

database/sql is really very light on docs.
It should be clearer about what works and what does not.
There should be a section about Scan conversions,
and that section can explain what the rules are.

That said, I don't think we should change NullString.
It is what it is, for better or worse.
Note that it is fairly straightforward to implement
a custom NullStringOrTime that picks off the
"value has type time.Time" case and handles it as
desired and then delegates to NullString for the rest.

It is easy to work around the problem, but it is also surprising (to me). The reason is that error says
error: unsupported driver -> Scan pair: time.Time -> *string
instead of something like
error: sql/driver: couldn't convert 5 into type bool
which is what you get run into a truly lossy conversion.

At the very least, the current behavior should be documented. But I don't think this behavior is correct and think we should fix.

It seems like a cop-out to use the loss of information rule as an excuse for not converting time.Time to a string. You can certainly encode a time, including its time zone, as a string without losing any information.

I would make the argument that time.Time should be converted to string because all of the other types mentioned in the Scanner interface are successfully converted into string. It is surprising that time.Time is not. It feels like an oversight, not an intentional decision.

In fact, are there are any Scanners in the standard library which handle time.Time?

The reason I bring this up is in the first place is that the only way to read a timestamp from a database using Scan is to know a columns contains a timestamp and provide a time.Time (or NullTime in libpq). Otherwise, it's straightforward to dump a table's contents into strings if you don't care. Instead, that's an error and you have to workaround the problem for times only. It's not like timestamps are a corner case of database either. They're very prevalent.

CL https://golang.org/cl/18935 mentions this issue.