Skip to content

BUG: GH11616 fixes timezone selection error #11672

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

varunkumar-dev
Copy link
Contributor

closes #11616
closes #11682

@jreback jreback added Bug Groupby Timezones Timezone data dtype labels Nov 23, 2015
@@ -1321,6 +1321,8 @@ def _possibly_downcast_to_dtype(result, dtype):
try:
result = result.astype(dtype)
except:
# convert to datetime and change timezone
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is too general. it can be a datetimelike (e.g. either M or m), and may or may not have a timezone. I think more tests are in order.

@jreback
Copy link
Contributor

jreback commented Nov 23, 2015

pls add a note in 0.18.0 bug fixes as well.

@jreback
Copy link
Contributor

jreback commented Nov 24, 2015

pls add a test for #11682 which I believe this should fix as well

@jreback jreback added this to the 0.18.0 milestone Nov 24, 2015
@varunkumar-dev
Copy link
Contributor Author

These errors are occurring for different reasons. First error #11616 is in _possibly_downcast_to_dtype. It is not able to retrieve correct date from int64 object. hence throwing an exception that I have fixed by checking for timezone info and then converting to correct timezone.
#11682 is in _infer_dtype_from_scalar function as correctly pointed out by ajenkins-cargometrics . We are checking for 'tz' attribute . I have fixed that by replacing 'tzinfo' and added test case for that.
Please review.

@@ -1321,6 +1321,9 @@ def _possibly_downcast_to_dtype(result, dtype):
try:
result = result.astype(dtype)
except:
if dtype.tz:
# convert to datetime and change timezone
result = pd.to_datetime(result).tz_localize(dtype.tz)
pass
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

don't need the pass here

@jreback
Copy link
Contributor

jreback commented Nov 25, 2015

looks good. pls add 2 entries in bug fixes in whatsnew for 0.18.0

@varunkumar-dev
Copy link
Contributor Author

Done. Please review.

@@ -105,3 +105,6 @@ Performance Improvements

Bug Fixes
~~~~~~~~~

- Bug in ``com._possibly_downcast_to_dtype`` not able to convert int64 object to correct datetime (:issue:`11616`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, use plain language from a user perspective; e.g. don't reference internal functions

Fixes GH11682 timzone info lost
@varunkumar-dev
Copy link
Contributor Author

@jreback One of the five Build job is failing . I am not able to figure out the reason . Please help.

@jreback
Copy link
Contributor

jreback commented Nov 27, 2015

merged via e838266

thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Groupby Timezones Timezone data dtype
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Timezone info lost when broadcasting scalar datetime to DataFrame groupby UTC timestamp aggregation
2 participants