You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Pandas compatibility of Timezone / Timezone Info #131
I think there is an incompatibility between pandas and pendulum.tz.timezone.Timezone. I'm not sure who is to blame though, but as from pendulum.tz.timezone_info.TimezoneInfo it seemed reasonable to check here first.
Two examples of unexpected behaviour; the programs exit with a segmentation fault:
I recon things go wrong when boxing in pandas. This is in C / Cython territory, so lot harder to debug for me.
Anyone ideas on the matter? I'd say Timezone probably behaves a bit different from TimezoneInfo but I really don't know where to start. I haven't even found their respective use cases yet.
Agreed that pandas should cover the return of None. At least not segfault ;) I've created an issue there. Thanks! Feel free to chip in over there :)
It did find it surprising that pendulum.tz.timezone.UTCTimezone and pendulum.tz.timezone_info.UTC behave differently. But I'll close this issue for now.
I think the main issue here is that pandas has some pretty heavy tight coupling with pytz and dateutil. They use all kinds of private methods in the dateutil time zone API to do what they are doing.
For fixed zones like UTC, I don't see that there's any harm in fast-tracking utcoffset() to return datetime.timedelta(0) (or equivalent), but for zones with DST, I think it's a pretty big overhaul for them to support generalized tzinfo objects. I imagine if you made a PR fixing it such that it didn't impact the performance of pytz and dateutil zones they'd merge it, but I doubt they'll prioritize this.
and it crashes, whatever the timezone of pend is...
Is there a direct way to get ceil(freq)and floor(freq)of a Pendulum?
Thanks for your job anyway.
EDIT
I tried ts = pd.Timestamp(pend, tz = pytz.tzinfo.tzinfo(pend.tz))
but still face the same issue : NotImplementedError: a tzinfo subclass must implement utcoffset()
I had to go back to UTC ts = pandas.Timestamp(pend.timezone_('UTC'), tz='UTC')
I just came across this issue, and the related Pandas one: pandas-dev/pandas#15986
after several days of frustration / confusion.
It seems that Pendulum is not 100% compatible with Pandas and some of the assumptions it makes about datetimes. I'm likely to now drop using it and revert to native datetime + pytz - which is a shame but I don't see a practical way round it given I use time indexed dataframes extensively.
I appreciate it can argued that the fault lies with Pandas and assumptions made there, but given that Pandas DataFrame / DateTimeIndexes are one of the main uses of Python Datetimes, it seems a bit disingenuous to present Pendulum as a drop-in replacement when these issues still exist (regardless of 'blame').
At the very least this should be highlighted in the Limitations section of the documentation so people are aware of this before they make the investment.
Activity
sdispater commentedon Jul 10, 2017
I investigated a bit and it seems that the segfault occurs when a call to
Timestamp.replace()is made here: https://github.com/pandas-dev/pandas/blob/master/pandas/core/indexes/datetimes.py#L484Behind the scene, pandas will call:
in the _get_dst_info() function.
However
total_seconds()assumes atimedeltawhile theutcoffset()method of atzinfocan also returnNone.Here is what the offical Python documentation says (https://docs.python.org/3.6/library/datetime.html#datetime.tzinfo.utcoffset):
And in this case
Noneis being passed toutcoffset()so there is no way to determine the offset that's why pendulum returnsNone.I am not sure how to approach this, but it seems to me that
pandasshould handle this special case since it's a documented one.frensjan commentedon Jul 11, 2017
Agreed that
pandasshould cover the return of None. At least not segfault ;) I've created an issue there. Thanks! Feel free to chip in over there :)It did find it surprising that
pendulum.tz.timezone.UTCTimezoneandpendulum.tz.timezone_info.UTCbehave differently. But I'll close this issue for now.frensjan commentedon Jul 12, 2017
Apparently this is a known issue at
pandasbut they won't fix it. Any suggestions?pganssle commentedon Jul 12, 2017
I think the main issue here is that
pandashas some pretty heavy tight coupling withpytzanddateutil. They use all kinds of private methods in thedateutiltime zone API to do what they are doing.For fixed zones like
UTC, I don't see that there's any harm in fast-trackingutcoffset()to returndatetime.timedelta(0)(or equivalent), but for zones with DST, I think it's a pretty big overhaul for them to support generalizedtzinfoobjects. I imagine if you made a PR fixing it such that it didn't impact the performance ofpytzanddateutilzones they'd merge it, but I doubt they'll prioritize this.matthiasLevy commentedon Jan 18, 2018
Hello !
Does anyone have found a workaround ?
Because the problems seems wider than just a problem in UTC. I just tried
and it crashes, whatever the timezone of pend is...
Is there a direct way to get
ceil(freq)andfloor(freq)of a Pendulum?Thanks for your job anyway.
EDIT
I tried
ts = pd.Timestamp(pend, tz = pytz.tzinfo.tzinfo(pend.tz))but still face the same issue :
NotImplementedError: a tzinfo subclass must implement utcoffset()I had to go back to UTC
ts = pandas.Timestamp(pend.timezone_('UTC'), tz='UTC')Expose Timezone._utcoffset property
rmaunder commentedon Jan 4, 2021
Hi
I just came across this issue, and the related Pandas one: pandas-dev/pandas#15986
after several days of frustration / confusion.
It seems that Pendulum is not 100% compatible with Pandas and some of the assumptions it makes about datetimes. I'm likely to now drop using it and revert to native datetime + pytz - which is a shame but I don't see a practical way round it given I use time indexed dataframes extensively.
I appreciate it can argued that the fault lies with Pandas and assumptions made there, but given that Pandas DataFrame / DateTimeIndexes are one of the main uses of Python Datetimes, it seems a bit disingenuous to present Pendulum as a drop-in replacement when these issues still exist (regardless of 'blame').
At the very least this should be highlighted in the Limitations section of the documentation so people are aware of this before they make the investment.