code review 7880045: database/sql: Add time.Time -> string/[]byte/RawBytes c...

database/sql: Add time.Time -> string/[]byte/RawBytes conversion

This conversion is intentional. It behaves just like fmt.Print(time) since it makes use of the same String() method

[julienschmidt, 2013-03-24 04:57:20]

Hello golang-dev@googlegroups.com (cc: bradfitz@golang.org,
golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[julienschmidt, 2013-03-24 04:58:56]

Alternatively the fmt.Stringer interface could be used to solve this more
general. But currently time.Time is the only driver.Value which makes use of it.

[rsc, 2013-03-25 20:27:53]

Sorry, but the time for API changes has passed. Please remind us about this
CL after Go 1.1 has been released.
http://golang.org/s/go11freeze

[bradfitz, 2013-06-05 22:25:28]

Julien,

Now that Go 1.1 is out, did you still want this to go in?

[julienschmidt, 2013-06-05 23:00:22]

I am not quite sure. The conversion from time.Time to other types should be 
added somehow, but this approach lacks the other way from string/[]bytes -> 
time.Time.
Maybe it is better to give the driver control over this formatting via a 
TimeFormatter interface or something like that.

Do you have a better idea?

On Thursday, June 6, 2013 12:25:28 AM UTC+2, Brad Fitzpatrick wrote:
>
> Julien, 
>
> Now that Go 1.1 is out, did you still want this to go in? 
>
>
> https://codereview.appspot.com/7880045/ 
>

[rsc, 2013-06-10 17:39:16]

This bothers me. Why is time.Time special?

[julienschmidt, 2013-06-10 19:07:20]

On 2013/06/10 17:39:16, rsc wrote:
> This bothers me. Why is time.Time special?

According to the SQL standard there are two valid formats for date values:
Without timezone: YYYY-MM-DD HH:MM:SS
With timezone: YYYY-MM-DD HH:MM:SS+offset (E.g. MySQL doesn't support timezones
at all while time.Time is always localized)

But not all DBMS comply with this SQL standard. In fact, the database/sql
package is not even just for SQL databases: "Package sql provides a generic
interface around SQL (or SQL-like) databases."

There a a few open questions:

time.Time -> string/ []byte / RawBytes:
* Which format should be used? The "Go format" (what this CL would do) or the
DBMS specific format? The latter would have the advantage that the output could
be used as a input for another query again.

string etc. -> time.Time:
* How does the database/sql package get the format necessary to parse the
string(-ish) value?
* How should values without timezone information be handled? Should an error be
returned? Should UTC / the local timezone be used?

[gobot, 2013-12-20 16:21:38]

Replacing golang-dev with golang-codereviews.

[bradfitz, 2014-01-14 21:39:16]

R=close

Feel free to re-open discussion if you're convinced this should go in, but I
think the supporting only time.Time -> time.Time is fine.  Then callers can
decide which string format they want and we don't have to decide and document.