Wrong DateTime value
akhobov opened this issue · comments
In case of tables with a datetime column that can be NULL this code generates a value with the current timestamp.
Line 131 in 4dd3d30
I guess it should be DateTime(time.Unix(0, 0).UTC()) so time.Time(strfmt.DateTime).IsZero() is true
I investigated this a little and I don't understand your statement about "current timestamp".
The DateTime{} initialization gives a "zero" of "01-01-0001T00:00:00.000Z" while the DateTime.IsZero() used UNIX zero time. I don't see any "current timestamp" there.
Anyhow, I don't think this choice of aligning DateTime's Zero to time.Unix(0,0) was ever a good idea.
other way around. The majority of languages use the unix 0 as their min date. And we always have to approach this from a language interop perspective. openapi sits at your application boundary, so following the principle of least surprise for your api consumers (for which in a public API you have no control over the language) they will expect unix min date.
Go compatibility is never the first driver of this, it's all about the other things that exist. It's trivial to compare against time.Unix(0,0) for a go programmer, for a javascript programmer it is a different story when they do new Date(0) they can never arrive at 01-01-0001T00:00:00:.000Z
They would also have to know that this is what represents no date and so on.
@casualjim : it is a matter of perspective...
Being raised as a database guy, and being born in the early 70's, I was never convinced that datetime should bear a specific relationship with unix timestamp...
You are talking language compatibility, but I am talking db compatibility.
And zeroing to 1/1/1970 breaks the no suprise principle when dealing with db's.
The point is semantics of datetime. You seem to think that datetime should be some kind of system timestamp. It is, on many occurences. But that's not the core semantics of this type in db (at least, any SQL db I have been tinkering with).
The way I addressed this in my own branch of this is to bring the "timestamp" semantics in the Scan() method reflect switch: when type is a numeric (say int64), we may infer that semantics are those of a timestamp and take the zero value of the numeric as a zero timestamp (hence 1/1/1970). In all other cases, zero value would take zero of time type (1/1/0001).
Ideally, we should have a "timestamp" format different from the "date-time"...
However, you did make a good point. if I am ever to contribute my own strfmt branch, I'll think about some kind of option to keep existing behavior unchanged. This story shall also be told...
Sorry guys for raising this issue. I guess I had quite a lot of things on my mind back at that time and didn't investigate the actual cause of the issue before opening this one.
This bug is actually invalid. The current code does generate the 01-01-0001T00:00:00:.000Z value in cases where a DB's timestamp value is NULL.
In the end I went with the *time.Time type (*strfmt.DateTime works too!) on that field. Using that type I'm getting the nil value for the rows with NULL timestamps. That way doesn't make any surprises as described by @fredbi and also can be propagated to the API level so API consumers don't need to check it against any "artificial" values as pointed out by @casualjim. The null value is a basic type in JSON so a check for it is trivial.
You can close this bug or give me a shout if you want me to to that.