Support TIMESTAMP_NTZ #962
Conversation
Tang8330
changed the title
| @@ -10,7 +10,7 @@ import ( | |||
| type Timestamp struct{} | |||
There was a problem hiding this comment.
- Timestamp
- MicroTimestamp
- NanoTimestamp
Do not contain any timezone information.
| @@ -56,6 +56,8 @@ func (MSSQLDialect) DataTypeForKind(kindDetails typing.KindDetails, isPk bool) s | |||
| case typing.ETime.Kind: | |||
| switch kindDetails.ExtendedTimeDetails.Type { | |||
| case ext.TimestampTzKindType: | |||
| return "datetimeoffset" | |||
There was a problem hiding this comment.
It looks like before, if we received a timestamp with tz/offset info, we discarded the tz and stored it without it. Now we'll start storing the tz. Is this change going to result in ddl changes to the column type of existing columns?
There was a problem hiding this comment.
Yes it will. I'll migrate the tables that are in MSSQL from datetime2 -> datetimeoffset once this change is in
There was a problem hiding this comment.
Actually, I don't think this would impact existing columns.
If the existing column is created as datetime2, we will then tag the column as TIMESTAMP_NTZ when we decipher the output from describe table.
When we merge our in-memory columns with existing, existing will take precedence.
It is then on the SDK to discard the tz information, which it should be doing already.
There was a problem hiding this comment.
Ah okay so we won't start storing the tz info for existing columns, but if a new column is created that should be tz-aware then we will store it. Seems reasonable 👍
| inMemoryCol.KindDetails.ExtendedTimeDetails.Format += ext.TimezoneOffset | ||
| } | ||
| } | ||
|
|
||
| // Just copy over the type since the format wouldn't be present in the destination |
There was a problem hiding this comment.
Is this comment still true?
There was a problem hiding this comment.
I think so, we're still not copying the layout from the destination columns.
The only logic we added is that if the destination column is TIMESTAMP_TZ and the in-memory column is TIMESTAMP_NTZ, we will append a timezone offset format to the in-memory column's format (if it's set).
Destinations
Update dialect
Backwards compatibility
This PR adds backwards compatibility by having a fallback format.
If the data type in the destination is created as
TIMESTAMP_TZand the values in Transfer are stored asTIMESTAMP_NTZ, then we should be returning it with the timezone locale to preserve our existing functionality.