|
|
|
Created:
12 years, 9 months ago by julienschmidt Modified:
11 years, 12 months ago CC:
golang-codereviews Visibility:
Public. |
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
Patch Set 1 #Patch Set 2 : diff -r c76d8e470353 https://code.google.com/p/go #Patch Set 3 : diff -r c76d8e470353 https://code.google.com/p/go #
Total messages: 9
|
julienschmidt
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
|
12 years, 9 months ago (2013年03月24日 04:57:20 UTC) #1 | |||||||||||||||||||||||
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
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.
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
Julien, Now that Go 1.1 is out, did you still want this to go in?
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/ >
This bothers me. Why is time.Time special?
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?
Replacing golang-dev with golang-codereviews.
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.