Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
database/sql: "Format3339Nano" not implemented; SQL TIMESTAMP -> Go Time doesn't work #24542
What version of Go are you using (
I believe it should be:
This is, in fact, what it uses when it encounters a
But this seems separate from your issue of
which shouldn’t hit the logic above.
Given this, what fix are you suggesting? (aside from correcting the documentation?)
RFC3339Nano is different from the format used by MySQL. Error message from trying to convert a MySQL TIMESTAMP field to a Go time.Time using an explicit call to "time.Parse(time.RFC3339Nano, stamp)"
RFC3339Nano requires a "T" before the time. MySQL has a space. So that's a no-go workaround.
The Format side (Go time.time -> SQL) is OK. It's the Parse side that's the problem.
Here's the real problem. Each SQL driver sends over the connection to the server some binary time format, which is supposed to be converted to the client platform (Go) time format down at that level. There's a little-known mode switch to enable this. See
To make it work right, add "
to the end of your DSN when opening the MySQL connection. Then, MySQL TIMESTAMP values convert to time.Time values properly. This is off by default. So, by default, the MySQL driver turns a TIMESTAMP into a string, The generic SQL driver has no parsing function to turn that into a time.Time.
Now, if you turn that switch on, TIMESTAMP to time.Time conversions work fine. But TIMESTAMP to Go "string" conversions then work differently. Now you get "2018-03-26T14:36:56Z" delivered into the Go string instead of "2018-03-26 14:08:01". So, if you turn that string on by default, it will probably break code that's expecting "2018-03-26 14:08:01" That's probably why somebody stuck in that mode switch.
So you're screwed. If you fix it right, you'll break code that's compatible with the legacy format.
There was discussion and a patch to fix all this back in 2016. See https://go-review.googlesource.com/c/go/+/18935 See that for background.
At least document this properly so it doesn't take two hours to figure it out. And tell the Gorm people, who've hit this problem.
The organizational dynamics of driver authors vs class-of-driver package authors I leave to you. From a user perspective, it should Just Work.
(I didn't classify this as a documentation bug. Gopherbot did. It's really a code bug. Classifier training problem?)
Let me please note that "Just Work" is a rather subjective term. I know of a company producing things said to "Just Work", but I am really not compatible with anything that company produces. So the quoted above has quite a different meaning to me.
I'm going to throw this issue in the same bucket as #22544 and other issues.
One way to phrase this: some databases aren't picky about types (sqlite, mysql) and sometimes we return strings from a db that we want to interpret as a time. Doing this conversion generically (as we currently attempt to do) is fine for many cases, but it is more inefficient then optimal and misses edge cases.
In the next week or two I want to come up with a better Scan implementation. But it will probably be substantially different then the current implementation.