ENH/SQL: support writing timestamps with timezone in to_sql

[jorisvandenbossche]

This currently works a bit for datetime values in the index (not in the columns, reason for this is that is then are object columns: #9085).
I say 'a bit', as it does give a 'timestamp with time zone' type (example for postgresql), but it is the time localized in your local timezone (I suppose because this is the way numpy works on input/output of datetimes).

In any case, also the code here (https://github.com/pydata/pandas/blob/v0.15.2/pandas/io/sql.py#L916) is not working (as columns never have a tzinfo attribute), and there are also no tests for this.

So in practice, timezones are not yet supported.

[ieow]

Hi,
any update on the timezone issue?

[oliveratutexas]

Also curious for updates!

[qris]

This causes problems with MS SQL Server, which can only have one timestamp column per table. If I try to write a table with two datetime(64) columns to SQL, I get this error:

"[42000] [Microsoft][ODBC SQL Server Driver][SQL Server]A table can only have one timestamp column. Because table 'close_data_temp' already has one, the column 'time_known' cannot be added. (2738) (SQLExecDirectW)"

SQLAlchemy says of this type (in dialects/mssql/base.py):

class TIMESTAMP(sqltypes._Binary):
    """Implement the SQL Server TIMESTAMP type.

    Note this is **completely different** than the SQL Standard
    TIMESTAMP type, which is not supported by SQL Server.  It
    is a read-only datatype that does not support INSERT of values.

I think the correct type to use for timezone-aware datetimes on SQL Server would be DATETIMEOFFSET, which is supported by SQLAlchemy. I can change this mapping locally by subclassing SQLTable and overriding _sqlalchemy_type, but it might be useful to support this natively if a SQL Server dialect is detected.

Please could this issue be reopened?