mssql: DATETIMEOFFSET: When transforming to UTC, use ISO 8601 convention

[detule]

Closes #946

In the previous release we introduced a SQL SERVER improvement where DATETIMEOFFSET data is automatically transformed into UTC and returned as POSIXct ( previously returned as strings containing the offset ). As part of that transformation we use cctz to transform the specified offset into a timezone and in turn into UTC time.

As it turns out there are competing (and opposing) conventions for the direction of the offset:

• POSIX: positive offset denotes time zone west of Greenwich.
• ISO8601: positive offset denotes time zone east of Greenwich.

We coded the feature to keep with the POSIX convention. However, I think it probably makes sense to convert to using ISO8601 since it is referenced in the Microsoft docs, although the docs don't specifically mention the direction of the offset.

The way coded in this patch, we make a clean break and note it in the release notes. Given that this is a breaking change, we could introduce a package option (odbc.mssql.tz_direction) or somesuch. I am slightly biased towards going with what's here since we've only had this code in for a few weeks/months, however can be swayed.

cc @r2evans

[r2evans]

I was not aware of the posix-v-iso8601 issue, that is ...... frustrating, it's bad enough that some vendors (like microsoft) implement standards in a more creative and selective way. I agree with your plan to stick with whichever method Microsoft implements. However, instead of or in addition to options(odbc.mssql.tz_direction=..) thought, is there anything in the ODBC standard where it might be a per-connection thing? I guess I'm just nervous that Microsoft's implementation may be sensitive to server-version, so it should be per-connection instead of on a per-process basis.

[simonpcouch]

I agree that we're okay to not introduce an option here. This seems reasonable to me!

Will defer to discussion between you and @r2evans on whether this is the best approach, but thumbs up from me if you end up feeling like this is indeed the way.

[detule]

... is there anything in the ODBC standard where it might be a per-connection thing? I guess I'm just nervous that Microsoft's implementation may be sensitive to server-version, so it should be per-connection instead of on a per-process basis.

Good question ( and I like the defensive thinking! ). I am not aware of any connection parameters or attributes that we can hijack for this purpose. On the other hand, I don't think we are dependent on any Microsoft implementation here since we are doing the offset-to-timezone conversion on our side. If they pulled the rug on us on anything upstream of that, I think there would be more widespread breakage.

[r2evans]

Are you familiar with nanodbc/nanodbc#432? If they provide native support for DATETIMEOFFSET then do we need to parse/interpret the offset here?

[detule]

Are you familiar with nanodbc/nanodbc#432? If they provide native support for DATETIMEOFFSET then do we need to parse/interpret the offset here?

Right - that's just code from our patch that we upstream-ed to nanodbc; i think there is no duplicated effort.