Data corruption: both "0000-00-00T00:00:00" and "0001-01-01T00:00:00" are parsed as time.Time's zero value

[mbyio]

Issue description

To be honest, I'm not sure what should happen, other than an error. But I don't think the current behavior (silently ignoring the problem) is okay because it results in incorrect output.

Basically the problem is MySQL supports storing impossible dates and times in DATETIME and TIMESTAMP columns. Obviously, this is terrible... but it is what it is at this point.

Go's time.Time value doesn't support invalid dates and times, which is great, except it means there's nowhere for a datetime of 0000-00-00T00:00:00 to go.

Right now, go-sql-driver/mysql converts both of these to Go's time.Time zero value, which is the date time 0001-01-01T00:00:00, which means sometimes people can get incorrect output.

My preference as a user is that the library returns an error if this condition is encountered. It would have been better if, originally, parseTime caused some custom struct like mysql.Time to be returned, which could at least indicate if there was a problem with parsing that particular datetime. Maybe we could add a new mode like parseMySQLTime where this is possible?

But silently corrupting data is not okay! (Even if that data is stupid and wrong...)

Possibly related to #683? I didn't get any errors while parsing though, and I was able to parse every row.

Configuration

Driver version (or git SHA): a0583e0

Go version: go1.9.1 darwin/amd64

Server version: MySQL 5.6

Server OS: Ubuntu

[methane]

I feel parseTime=false is enough for such rare cases.
I don't want to add more options.

[mbyio]

Sure, if you don't want to return an error to let people know what's going on, maybe you could at least add a note in the documentation saying parseTime=true could return undefined results if MySQL's DATETIME or TIMESTAMP value is out of the range that can be represented by time.Time?

[dolmen]

You can always implement your own type that implements the sql.Scanner interface if you want to parse the value by yourself and distinguish such edge cases.