API: Localize Series when calling to_datetime with utc=True (#6415) #17109

mroeschke · 2017-07-29T06:19:28Z

closes BUG: to_datetime ignores utc=True when arg is Series #6415
tests added / passed
passes git diff upstream/master -u -- "*.py" | flake8 --diff
whatsnew entry

When _convert_listlike passes a np.array into a Series, the Series seems to initially be of naive datetime dtype. Localized Series if utc=True.

I made one minor change to an existing test that tz_localize and index when it originally set the index with a Series with pd.to_datetime(...utc=True).

gfyoung · 2017-07-29T06:26:13Z

pandas/tests/test_multilevel.py

@@ -2130,7 +2130,7 @@ def test_set_index_datetime(self):
                          '2011-07-19 08:00:00', '2011-07-19 09:00:00'],
             'value': range(6)})
        df.index = pd.to_datetime(df.pop('datetime'), utc=True)
-        df.index = df.index.tz_localize('UTC').tz_convert('US/Pacific')
+        df.index = df.index.tz_convert('US/Pacific')


Just for future reference, can you explain here why you needed to change this test?

jreback · 2017-07-29T12:22:04Z

pandas/core/tools/datetimes.py

@@ -508,6 +508,10 @@ def _convert_listlike(arg, box, format, name=None, tz=tz):
        from pandas import Series
        values = _convert_listlike(arg._values, False, format)
        result = Series(values, index=arg.index, name=arg.name)
+        if utc and isinstance(values, np.ndarray):


should be inside convert_list_like

I'm not sure how to include this logic in convert_listlike as is.

._values is called on Series before it's passed into convert_listlike which turns the Series into a np.array, so convert_listlike doesn't "know" that a Series was the original argument.

Not sure why this was done originally, but I could have convert_listlike handle a Series directly?

not sure how easy that is, but you could.

jreback · 2017-07-29T12:22:18Z

pandas/tests/indexes/datetimes/test_tools.py

@@ -270,6 +270,32 @@ def test_to_datetime_utc_is_true(self):
        expected = pd.DatetimeIndex(data=date_range)
        tm.assert_index_equal(result, expected)

+        # GH 6415: UTC=True with Series
+        data = ['20100102 121314', '20100102 121315']


make a new test

jreback · 2017-07-29T12:23:12Z

pandas/tests/indexes/datetimes/test_tools.py

+        data = ['20100102 121314', '20100102 121315']
+        result = pd.to_datetime(pd.Series(data),
+                                format='%Y%m%d %H%M%S',
+                                utc=True)


this should work if box is True iow an Index or Series is passed

jreback · 2017-07-29T12:23:54Z

doc/source/whatsnew/v0.21.0.txt

@@ -260,7 +260,7 @@ Conversion

 - Bug in assignment against datetime-like data with ``int`` may incorrectly converte to datetime-like (:issue:`14145`)
 - Bug in assignment against ``int64`` data with ``np.ndarray`` with ``float64`` dtype may keep ``int64`` dtype (:issue:`14001`)
-
+- Bug in :func:`to_datetime` incorrectly localizing dates in `Series` when `utc=True` (:issue:`6415`)


this needs a sub section as it's a major change

What section in the whatsnew should I put this under? Enhancement? API breaking?

I feel like this an API breaking change. Enhancement implies it adds functionality that's beneficial and isn't patching existing behavior per se.

this is a major change that is API breaking.

jreback · 2017-08-07T10:56:00Z

doc/source/whatsnew/v0.21.0.txt

+UTC Localization with Series
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Previously, :func:`to_datetime` did not localize datetime ``Series`` data as when ``utc=True`` was passed. Now, :func:`to_datetime`


just say what its going to do, this is redundant otherwise.

jreback · 2017-08-07T10:56:11Z

doc/source/whatsnew/v0.21.0.txt

+Previously, :func:`to_datetime` did not localize datetime ``Series`` data as when ``utc=True`` was passed. Now, :func:`to_datetime`
+will correctly localize `Series` with a `datetime64[ns, UTC]` data type. (:issue:`6415`)
+
+  Old Behavior


previous behaviour

jreback · 2017-08-07T10:58:04Z

pandas/core/tools/datetimes.py

@@ -359,7 +359,9 @@ def _convert_listlike(arg, box, format, name=None, tz=tz):
                    return DatetimeIndex(arg, tz=tz, name=name)
                except ValueError:
                    pass
-
+            from pandas import Series


this should also work for a DTI.

use ABCSeries rather than importing.

I am not sure this is the best location for this.

jreback · 2017-08-07T10:58:32Z

pandas/core/tools/datetimes.py

@@ -379,11 +381,12 @@ def _convert_listlike(arg, box, format, name=None, tz=tz):
            raise TypeError('arg must be a string, datetime, list, tuple, '
                            '1-d array, or Series')

-        arg = _ensure_object(arg)
+        obj_arg = _ensure_object(arg)


why are you changing this?

Since I was trying to have _convert_listlike handle Series arguments directly, I was using the arg variable to keep track if a Series was initially passed so I know to use dt.tz_localize() after the dates have been parsed. arg = _ensure_object(arg) converts arg from a Series to a np.array so I no longer know what data structure was originally passed.

I guess I could create a boolean variable arg_is_seriesin the beginning and keep track of this information that way.

can you revert the obj_arg thing, hard to tell what's changing here

jreback · 2017-08-07T10:58:59Z

pandas/core/tools/datetimes.py

            if is_datetime64_dtype(result) and box:
                result = DatetimeIndex(result, tz=tz, name=name)
+            # GH 6415


too specific change here I think (see my comment above)

better to make a wrapper function which handles the utc argument (IOW if its a DTI / Series and utc is true it will localize, otherwise it will pass thru).

jreback · 2017-08-07T10:59:35Z

pandas/tests/indexes/datetimes/test_tools.py

@@ -270,6 +270,38 @@ def test_to_datetime_utc_is_true(self):
        expected = pd.DatetimeIndex(data=date_range)


you didn't have to change any tests here?

You mentioned previously to move these tests to their own function. Is that what you were referring to?

jreback · 2017-08-08T11:08:32Z

doc/source/whatsnew/v0.21.0.txt

+UTC Localization with Series
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+:func:`to_datetime` now correctly localizes datetime ``Series`` data as when ``utc=True`` was passed with 


remove correctly. localizes to UTC when utc=True is passed

jreback · 2017-08-08T11:09:08Z

pandas/core/tools/datetimes.py

+            if isinstance(arg, ABCSeries):
+                arg = arg.dt.tz_localize('UTC')
+            elif isinstance(arg, DatetimeIndex):
+                arg = arg.tz_convert(None).tz_localize('UTC')


hmm, why are you converting to naive for a DTI?

jreback · 2017-08-08T11:09:40Z

pandas/core/tools/datetimes.py

@@ -379,11 +381,12 @@ def _convert_listlike(arg, box, format, name=None, tz=tz):
            raise TypeError('arg must be a string, datetime, list, tuple, '
                            '1-d array, or Series')

-        arg = _ensure_object(arg)
+        obj_arg = _ensure_object(arg)


can you revert the obj_arg thing, hard to tell what's changing here

mroeschke · 2017-08-10T05:36:09Z

I noticed that some IO SQL tests have been failing.

It appears that in the conversion from SQL to DataFrame the function _handle_date_column has pd.to_datetime(..., utc=True) hardcoded which is now localizing the columns to utc by default after this fix.

I feel we shouldn't assume these database dates are utc by default i.e. remove hardcoded utc=True. Thoughts?

jorisvandenbossche · 2017-08-10T09:30:35Z

@mroeschke yeah, that sql issue might be a tricky issue, as I recall we had a long discussion about that. The utc=True was added in #7364.
It was done to deal with datetime objects with timezones coming from the database. The end result of using utc=True was that we always converted the timezone aware data to naive utc.

But, that also dates back from the time that a Series could not hold timezone aware data. So now, I think it would be OK (or even better) to have it as timezone aware but still UTC data (the reason that it has to be utc, if I recall, is that the database uses fixed offsets, which can lead to different timezones around DST, which results in errors when converting that to a datetime64 column. Therefore we decided to always convert timezone aware data to UTC)

So given that, it might be that we just need to update the tests?

jreback · 2017-08-10T09:58:32Z

actually the db issue might be more complex and just changing tests is not the correct thing to do. See what is actually returned currently in the database. IIRC postgres stores a datetime-aware tz, but its actually in the local timezone, IOW it loses the offset info (it does convert to UTC from wherever it was, it just stores it locally). SO you need to reverse this on de-serialization.

@cpcloud

jorisvandenbossche · 2017-08-10T10:03:52Z

@jreback looking at the issues I linked to (but it is a long time ago I actually looked at it ..), the data we get from postgres are datetime objects with ~~pytz~~ psycopg2 fixed offsets (so no actual timezone). So I think converting to UTC is, as we decided back then, still the most sensible thing to do (up to now, it only looses the 'utc time zone' as Series back then didn't support having a timezone. So now we can still have a utc data, but just preserve the fact it is timezone aware)

jreback · 2017-08-10T10:23:44Z

@jorisvandenbossche postgres loses information in the timezone. They are UTC dates, but in the local timezone. you need to match the existing behavior.

jorisvandenbossche · 2017-08-10T10:31:33Z

you need to match the existing behavior.

Sorry, what do you mean? Do you mean existing behaviour of read_sql?
As I already said, read_sql already returns utc data for 'timestamp with time zone' data (so how postgres stores them). It now only converts it to "utc naive data" (as Series could not hold timezone information), which is due to the changes in this PR changes to "utc aware data", so the same values, but now with the timezone information.
IMO this change is not necessarily bad (I think it would have done that in #7364 if it had been possible at that time)

mroeschke · 2017-08-11T23:40:01Z

I agree with @jorisvandenbossche

For reference, postgres timestamp with time zone is stored in UTC, and upon output:

it is always converted from UTC to the current timezone zone, and displayed as local time in that zone

But more importantly, the psycopg2 driver returns datetime objects with psycopg2.tz.FixedOffsetTimezone, and since this has historically been converted to UTC (naive), keeping it UTC sounds good to me (but now aware after this PR). I can add an additional note in the whatsnew

pep8speaks · 2017-08-15T04:35:05Z

Hello @mroeschke! Thanks for updating the PR.

Cheers ! There are no PEP8 issues in this Pull Request. 🍻

Comment last updated on September 01, 2017 at 07:00 Hours UTC

codecov · 2017-08-15T05:35:27Z

Codecov Report

Merging #17109 into master will decrease coverage by 0.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master   #17109      +/-   ##
==========================================
- Coverage   91.03%   91.02%   -0.02%     
==========================================
  Files         163      163              
  Lines       49580    49581       +1     
==========================================
- Hits        45137    45130       -7     
- Misses       4443     4451       +8

Flag	Coverage Δ
#multiple	`88.8% <28.57%> (-0.01%)`	⬇️
#single	`40.26% <100%> (-0.06%)`	⬇️

Impacted Files	Coverage Δ
pandas/core/tools/datetimes.py	`67.3% <100%> (+0.27%)`	⬆️
pandas/io/sql.py	`94.8% <100%> (ø)`	⬆️
pandas/io/gbq.py	`25% <0%> (-58.34%)`	⬇️
pandas/core/frame.py	`97.72% <0%> (-0.1%)`	⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 062f6f1...5eb7d9c. Read the comment docs.

jreback · 2017-08-15T10:33:56Z

doc/source/whatsnew/v0.21.0.txt

+
+     pd.to_datetime(s, utc=True)
+
+This new behavior will also localize datetime columns in DataFrames returned from :func:`read_sql` which previously returned datetime columns as naive UTC.


this is would fighten me. you have to be expicit that this is only for columns that are already datetime tz-aware.

jreback · 2017-08-15T10:34:05Z

doc/source/whatsnew/v0.21.0.txt

+.. _whatsnew_0210.api.utc_localization_with_series:
+
+UTC Localization with Series
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^


issue number and provide a short expl.

jreback · 2017-08-15T10:35:10Z

pandas/core/tools/datetimes.py

+                if arg.tz is None:
+                    arg = arg.tz_localize('UTC')
+                else:
+                    arg = arg.tz_convert('UTC')


this is a BIG change here. we don't convert existing tz-aware timezones. why are you doing this?

jreback · 2017-08-15T10:36:16Z

pandas/core/tools/datetimes.py

            if is_datetime64_dtype(result) and box:
                result = DatetimeIndex(result, tz=tz, name=name)
+            # GH 6415
+            elif arg_is_series and utc:


this is kludgy. pls find a better way.

The reason why I am doing this is because a Series is converted to a numpy array for the date conversion, and _convert_listlike needs an indicator to return back a Series.

The alternative is to have _convert_listlike return an array and have to_datetime do the conversion and localization. Which option is preferable?

ok, name this is_series and do this outside of the convert_listlike function.

you don't need this if here, instead do it inside the maybe_convert_to_utc function

I think (didn't look in detail) that this kludgyness is coming from the fact that for a Series _convert_listlike now converts an array (box is to False when dealing with a Series), while for DatetimeIndex is returns a DatetimeIndex. And, an array cannot hold tz aware data, so the utc keyword needs to be handles separately for Series and DatetimeIndex, when using this current implementation.

But, can't we just remove the box=False for converting Series objects? And so unify the code for returning Series vs DatetimeIndex (conversion from DatetimeIndex to Series (instead of from array to Series) should be rather performant?)

@jorisvandenbossche right idea but not directly related to box.

_convert_listlike can essentially be summarized in two operations:

If the data already has a datetime dtype, take a short cut.

Otherwise, make sure the data is of object dtype and try to parse.

In step 2, a Series is passed into _ensure_object which turns a Series into a numpy array with object dtype. Therefore, the kludge is due to attempting to have _convert_listlike "remember" that a Series was passed.

But sure, I can try to move this to the _maybe_convert_to_utc function

OK, but for for step 2, why do you then need to have _convert_listlike handle Series vs arrays/lists of strings differently?
(As far as I can see, this is because for a Series the values are not converted to a DatetimeIndex at the end of _convert_listlike, and so the handling of utc has to be done afterwards again, but I can be wrong)

My first fix for this issue was to have _convert_listlike just return an array and have to_datetime feed that array into a Series constructor and then localize to utc. To avoid leaking the conversion logic out of _convert_listlike, I am trying to have _convert_listlike return a localized Series outright.

So yes, for a Series the values are not converted to a DatetimeIndex (which can handle the localization with the tz arg) at the end of _convert_listlike, and when passing the values to a Series constructor, an extra step is need to localize the Series to utc i.e. Series(converted_array).dt.tz_localize('UTC')

So my suggestion is: can't we just also for Series return a DatetimeIndex (which already handles the utc keyword fine), and then afterwards just convert this to a Series as we now convert the array to a Series (then there is no need to either leak the conversion out of _convert_listlike or to deal with Series construction inside _convert_listlike).
(but it might be that there are other reasons for having it as an array that might break, I don't know)

jreback · 2017-08-15T22:33:15Z

pandas/tests/indexes/datetimes/test_tools.py

+                                utc=True)
+        expected = pd.Series(expected_data)
+        tm.assert_series_equal(result, expected)
+        result = pd.to_datetime(pd.Index(data),


use blank lines in between different sub-tests

instead of duplicating lots of code, break this big tests into separate tests and use parametrize to deal with Series/Index converions

jreback · 2017-08-15T22:35:38Z

pandas/tests/io/test_sql.py

@@ -1319,14 +1323,15 @@ def check(col):
    def test_date_parsing(self):
        # No Parsing
        df = sql.read_sql_table("types_test_data", self.conn)
-
+        # Now that GH 6415 is fixed, dates are automatically parsed to UTC


write these reversed, IOW

dates are automatically parsed to UTC (GH 6415). A future reader likely won't look at the reference unless the comment is not good enough., the comment needs to stand on its own.

jreback · 2017-08-15T22:36:34Z

pandas/tests/io/test_sql.py

@@ -1352,7 +1357,11 @@ def test_datetime(self):
        # with read_table -> type information from schema used
        result = sql.read_sql_table('test_datetime', self.conn)
        result = result.drop('index', axis=1)
-        tm.assert_frame_equal(result, df)
+        # After GH 6415, dates outbound from a db will be localized to UTC


what happens if d.Af is localized to UTC (IOW before to_sql). does it work?

jreback · 2017-08-15T22:37:10Z

pandas/tests/io/test_sql.py

-        # comes back as datetime64
-        tm.assert_series_equal(res['a'], to_datetime(df['a']))
+        # GH 6415 comes back as datetime64[ns, UTC]
+        tm.assert_series_equal(res['a'], to_datetime(df['a'], utc=True))


use result, expected here, otherwise too hard to read

jorisvandenbossche · 2017-08-15T22:48:11Z

@mroeschke Based on the diff in the sql tests, it seems that you now have read_sql to return UTC aware data always (is this correct?), while IMO we should only return tz aware data when the SQL type is timestamp with time zone, and still return plain tz naive datetime data when the SQL type is just timestamp

mroeschke · 2017-08-16T05:43:32Z

@jorisvandenbossche Ah yes, you're right. I think I was too aggressive in changing the SQL tests.

I will have to dig deeper into SQL routines to see if I can determine the original SQL type and pass that info along to the _handle_date_column function which is now making datetime columns tz aware with to_datetime(..., utc=True)

mroeschke · 2017-08-30T06:22:38Z

Addressed your comments @jorisvandenbossche and all green.

jreback · 2017-08-30T10:30:29Z

pandas/io/sql.py

@@ -821,7 +821,12 @@ def _harmonize_columns(self, parse_dates=None):

                if (col_type is datetime or col_type is date or
                        col_type is DatetimeTZDtype):
-                    self.frame[col_name] = _handle_date_column(df_col)
+                    if col_type is DatetimeTZDtype:


just

utc = col_type is DatetimeTZDtype self.frame[.....] = _handle_date_column(df_col, utc=utc)

jreback · 2017-08-30T10:30:40Z

doc/source/whatsnew/v0.21.0.txt

+UTC Localization with Series
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Previously, :func:`to_datetime` did not localize datetime ``Series`` data when ``utc=True`` was passed. Now, :func:`to_datetime` will correctly localize `Series` with a `datetime64[ns, UTC]` data type to be consistent with how list-like and Index data are handled. (:issue:`6415`).


use double backticks around Index and Series

also around the datetime64[ns, UTC]; otherwise these get lost in the text

say dtype instead of 'data type'

jreback · 2017-08-30T10:32:25Z

pandas/tests/io/test_sql.py

-                               .astype('datetime64[ns, UTC]'))
+        col = expected.DateColWithTz
+        assert is_datetime64tz_dtype(col.dtype)
+        # Removed ".astype('datetime64[ns, UTC]')"after GH 6415 was fixed


remove this comment; you can explain why things are, but refering to the past is confusing

jreback · 2017-08-30T10:33:03Z

pandas/tests/test_multilevel.py

@@ -2130,7 +2130,8 @@ def test_set_index_datetime(self):
                          '2011-07-19 08:00:00', '2011-07-19 09:00:00'],
             'value': range(6)})
        df.index = pd.to_datetime(df.pop('datetime'), utc=True)
-        df.index = df.index.tz_localize('UTC').tz_convert('US/Pacific')
+        # Removed 'tz_localize('utc') below after GH 6415 was fixed


jorisvandenbossche · 2017-08-30T13:25:41Z

pandas/tests/indexes/datetimes/test_tools.py

+                             [('2013-01-01 00:00:00-01:00', None),
+                              ('2013-01-01 00:00:00-01:00', 'datetime64[ns]'),
+                              ('2013-01-01 01:00:00', None),
+                              ('2013-01-01 01:00:00', 'datetime64[ns]')])


You can write this a bit shorter by doing:

@pytest.mark.parametrize("data", ['2013-01-01 00:00:00-01:00', '2013-01-01 00:00:00-01:00']) @pytest.mark.parametrize("dtype", [None, 'datetime64[ns]']) def test...

then you get all combinations of the two automatically.

But I still don't fully understand the point of the test (or for the '2013-01-01 01:00:00' case. Isn't that covered by the test above?)

What is not tested above is a string that included tz offset, or a series with an already datetime64 dtype (both aware or naive) So I would just test those two cases? (and both also seem distinct, so would put them in different tests)

Modify test case Comment about test edit, move conversion logic to convert_listlike Add new section in whatsnew and update test Alter SQL tests Modify whatsnew and make new wrapper function to handle UTC conversion Simiplified whatsnew and reverted arg renaming

…tests

mroeschke · 2017-09-01T07:20:16Z

Fixed the whatsnew and extraneous comments and created additional tests for tz-aware strings and Series with datetime[ns] dtypes.

I also stumbled upon this inconsistency when I was trying to add an additional test for 'datetime[ns, CET]' dtype:

In [3]: pd.Series(['2013-01-01 00:00:00'], dtype='datetime64[ns, CET]')
Out[3]: 
0   2013-01-01 01:00:00+01:00
dtype: datetime64[ns, CET]

In [4]: pd.Series([pd.Timestamp('2013-01-01 00:00:00', tz='CET')])
   ...: 
Out[4]: 
0   2013-01-01 00:00:00+01:00
dtype: datetime64[ns, CET]

I think these should be consistent and Out[4] should be the correct behavior. Thoughts? If so, I can add a new issue and maybe a test in this PR that will xfail due to this.

jorisvandenbossche · 2017-09-01T12:14:20Z

I think all outstanding comments were addressed now, so time to finally get this merged :-)

I also stumbled upon this inconsistency when I was trying to add an additional test for 'datetime[ns, CET]' dtype:

I think Out[4] is certainly correct, for the Out[3]: I am not really sure.
(but I would certainly keep this for a separate issue / PR)

…ev#6415) (pandas-dev#17109)

gfyoung added Bug Timezones Timezone data dtype labels Jul 29, 2017

gfyoung reviewed Jul 29, 2017

View reviewed changes

gfyoung approved these changes Jul 29, 2017

View reviewed changes

jreback requested changes Jul 29, 2017

View reviewed changes

mroeschke force-pushed the fix_6415 branch 2 times, most recently from 12b9c58 to e85263d Compare August 7, 2017 05:28

jreback requested changes Aug 7, 2017

View reviewed changes

jreback requested changes Aug 8, 2017

View reviewed changes

mroeschke force-pushed the fix_6415 branch from 3a172ba to 7990c5b Compare August 10, 2017 05:13

jorisvandenbossche added this to the 0.21.0 milestone Aug 10, 2017

jreback requested changes Aug 15, 2017

View reviewed changes

jreback removed this from the 0.21.0 milestone Aug 15, 2017

jreback changed the title ~~BUG: Localize Series when calling to_datetime with utc=True (#6415)~~ API: Localize Series when calling to_datetime with utc=True (#6415) Aug 15, 2017

jreback added API Design and removed Bug labels Aug 15, 2017

jreback requested changes Aug 15, 2017

View reviewed changes

jorisvandenbossche added this to the 0.21.0 milestone Aug 15, 2017

jreback requested changes Aug 30, 2017

View reviewed changes

jorisvandenbossche reviewed Aug 30, 2017

View reviewed changes

mroeschke added 16 commits August 31, 2017 23:50

Fxi merge

b846c57

Adjust SQL tests

9a93811

Add whatsnew note about impact on read_sql

76471e9

PEP8 fixes

eed2d3d

Have DatetimeIndex handle the UTC conversion for Series and reformat …

f56859a

…tests

Address whatsnew changes & fix sql tests

d069b05

Undo formatting

f24b82c

Revert SQL test

808a810

Address comments and confirm timezone tests

c142975

Ensure expected name matches

e8f5d4e

Fix linting errors

4d17722

Whatsnew and tests fixups

9e9b89e

Address whatsnew and test comments

d466fd2

Fix linting errors

177b3fe

Fix tests and whatnew notes

3407830

mroeschke force-pushed the fix_6415 branch from f487995 to 3407830 Compare September 1, 2017 06:55

mroeschke added 2 commits August 31, 2017 23:57

Remove extra linebreak

f9248ad

Double tick Index

5eb7d9c

jorisvandenbossche approved these changes Sep 1, 2017

View reviewed changes

jorisvandenbossche merged commit dad39d5 into pandas-dev:master Sep 1, 2017

jreback mentioned this pull request Sep 1, 2017

DEPS: Added tz keyword to to_datetime function, deprecates utc #17413

Closed

4 tasks

jowens pushed a commit to jowens/pandas that referenced this pull request Sep 20, 2017

API: Localize Series when calling to_datetime with utc=True (pandas-d…

c80e8d0

…ev#6415) (pandas-dev#17109)

alanbato pushed a commit to alanbato/pandas that referenced this pull request Nov 10, 2017

API: Localize Series when calling to_datetime with utc=True (pandas-d…

281c067

…ev#6415) (pandas-dev#17109)

mroeschke deleted the fix_6415 branch December 20, 2017 02:04

		@@ -270,6 +270,38 @@ def test_to_datetime_utc_is_true(self):
		expected = pd.DatetimeIndex(data=date_range)


		pd.to_datetime(s, utc=True)

		This new behavior will also localize datetime columns in DataFrames returned from :func:`read_sql` which previously returned datetime columns as naive UTC.

API: Localize Series when calling to_datetime with utc=True (#6415) #17109

API: Localize Series when calling to_datetime with utc=True (#6415) #17109

Conversation

mroeschke commented Jul 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mroeschke Aug 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mroeschke commented Aug 10, 2017

jorisvandenbossche commented Aug 10, 2017

jreback commented Aug 10, 2017

jorisvandenbossche commented Aug 10, 2017 • edited Loading

jreback commented Aug 10, 2017

jorisvandenbossche commented Aug 10, 2017 • edited Loading

mroeschke commented Aug 11, 2017

pep8speaks commented Aug 15, 2017 • edited Loading

Comment last updated on September 01, 2017 at 07:00 Hours UTC

codecov bot commented Aug 15, 2017 • edited Loading

Codecov Report

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mroeschke Aug 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorisvandenbossche Aug 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jorisvandenbossche commented Aug 15, 2017

mroeschke commented Aug 16, 2017 • edited Loading

mroeschke commented Aug 30, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mroeschke commented Sep 1, 2017

jorisvandenbossche commented Sep 1, 2017

mroeschke Aug 7, 2017 •

edited

Loading

jorisvandenbossche commented Aug 10, 2017 •

edited

Loading

jorisvandenbossche commented Aug 10, 2017 •

edited

Loading

pep8speaks commented Aug 15, 2017 •

edited

Loading

codecov bot commented Aug 15, 2017 •

edited

Loading

mroeschke Aug 16, 2017 •

edited

Loading

jorisvandenbossche Aug 16, 2017 •

edited

Loading

mroeschke commented Aug 16, 2017 •

edited

Loading