Skip to content

BUG: conversion precision on Timedeltas #14156

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
jreback opened this issue Sep 5, 2016 · 3 comments · Fixed by #19732
Closed

BUG: conversion precision on Timedeltas #14156

jreback opened this issue Sep 5, 2016 · 3 comments · Fixed by #19732
Labels
Bug Timedelta Timedelta data type
Milestone

Comments

@jreback
Copy link
Contributor

jreback commented Sep 5, 2016

I think this is rounding prematurely, though not entirely sure. Could also just be loss of precision when converting from a float -> int64.

In [12]: pd.to_datetime(1434743731.8770001,unit='s')
Out[12]: Timestamp('2015-06-19 19:55:31.877000')

In [13]: pd.to_datetime(1434743731.8770001,unit='s').value
Out[13]: 1434743731877000000

In [14]: (pd.Timestamp('2015-06-19 19:55:15.877000')+pd.Timedelta('1us')).value
Out[14]: 1434743715877001000

@jorisvandenbossche
Copy link
Member

Copying from #19680

It happens in this function:

In [126]: pd._libs.tslibs.timedeltas.cast_from_unit(1.5e-6, 's')
Out[126]: 2000

because we round at 6 decimals:

elif unit == 's':
m = 1000000000L
p = 6

frac = round(frac, p)

Not fully sure why we choose 6 decimals to be allowed, and not 9 in case of 's' (and 6 in case of 'ms', 3 for 'us', ..)

@Sup3rGeo
Copy link
Contributor

Isn't this the same as #12690?

@jorisvandenbossche
Copy link
Member

Indeed, will close the other in favor of this one. Thanks for noticing!

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

Successfully merging a pull request may close this issue.

3 participants