ENH: Support writing timestamps with timezones with to_sql

doc/source/whatsnew/v0.24.0.txt

@@ -462,35 +462,6 @@ that the dates have been converted to UTC
 
     pd.to_datetime(["2015-11-18 15:30:00+05:30", "2015-11-18 16:30:00+06:30"], utc=True)
 
-.. _whatsnew_0240.api_breaking.timezone_databases:
-
-Writing Timezone Aware Data to Databases
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-:meth:`to_sql` can now write timezone aware datetime data (``datetime64[ns, tz]`` dtype)
-as ``TIMESTAMP WITH TIME ZONE`` type to databases that support that type. (:issue:`9086`)
-
-However, databases that do not support timezones will now store timezone aware data
-as naive timestamps in local time instead of naive timestamps in UTC.
-
-Therefore, round-tripping timezone aware data from pandas to a database and back
-to pandas has changed behavior. Given timezone aware data that has been
-written to a database from pandas, the following table summarizes
-the timestamps that will be returned.
-
-+----------+--------------------------------+-----------------------------------+
-|          | Database with timezone support | Database without timezone support |
-+==========+================================+===================================+
-| Before   | tz-naive in UTC time           | tz-naive in UTC time              |
-+----------+--------------------------------+-----------------------------------+
-| After    | tz-aware in UTC time           | tz-naive in local time            |
-+----------+--------------------------------+-----------------------------------+
-
-Converting timezones read from ``TIMESTAMP WITH TIME ZONE`` types to UTC is
-consistent with prior behavior.
-
-See the :ref:`io.sql_datetime_data` for more information.
-
 .. _whatsnew_0240.api_breaking.calendarday:
 
 CalendarDay Offset
@@ -1275,6 +1246,9 @@ MultiIndex
 I/O
 ^^^
 
+- Bug in :meth:`to_sql` when writing timezone aware data (``datetime64[ns, tz]`` dtype) would raise a ``TypeError`` (:issue:`9086`)
+- Bug in :meth:`to_sql` where a naive DatetimeIndex would be written as ``TIMESTAMP WITH TIMEZONE`` type in supported databases, e.g. PostgreSQL (:issue:`23510`)
+
 .. _whatsnew_0240.bug_fixes.nan_with_str_dtype:
 
 Proper handling of `np.NaN` in a string data-typed column with the Python engine

pandas/io/sql.py

@@ -852,8 +852,13 @@ def _sqlalchemy_type(self, col):
         if col_type == 'datetime64' or col_type == 'datetime':
             # GH 9086: TIMESTAMP is the suggested type if the column contains
             # timezone information
-            if col.dt.tz is not None:
-                return TIMESTAMP(timezone=True)
+            try:
+                if col.dt.tz is not None:
+                    return TIMESTAMP(timezone=True)
+            except AttributeError:
+                # The column is actually a DatetimeIndex
+                if col.tz is not None:
+                    return TIMESTAMP(timezone=True)
             return DateTime
         if col_type == 'timedelta64':
             warnings.warn("the 'timedelta' type is not supported, and will be "

pandas/tests/io/test_sql.py

@@ -1391,6 +1391,17 @@ def test_datetime_with_timezone_roundtrip(self):
             result['A'] = to_datetime(result['A'])
         tm.assert_frame_equal(result, expected)
 
+    def test_naive_datetimeindex_roundtrip(self):
+        # GH 23510
+        # Ensure that a naive DatetimeIndex isn't converted to UTC
+        dates = date_range('2018-01-01', periods=5, freq='6H')
+        expected = DataFrame({'nums': range(5)}, index=dates)
+        expected.to_sql('foo_table', self.conn, index_label='info_date')
+        result = sql.read_sql_table('foo_table', self.conn,
+                                    index_col='info_date')
+        # result index with gain a name from a set_index operation; expected
+        tm.assert_frame_equal(result, expected, check_names=False)
+
     def test_date_parsing(self):
         # No Parsing
         df = sql.read_sql_table("types_test_data", self.conn)