ENH: DatetimeTZDtype support non-nano #47120
Conversation
jreback
added
Non-Nano
| with pytest.raises(ValueError, match=msg): | ||
| DatetimeTZDtype("ms", "US/Eastern") | ||
| def test_construction_non_nanosecond(self): | ||
| res = DatetimeTZDtype("ms", "US/Eastern") |
There was a problem hiding this comment.
Is the DatetimeTZDtype("D", "US/Eastern") raising case tested in this file as well?
Also would be good to have a full smoke test from one of the 1D constructors e.g. pd.array('2022-01-01', dtype='datetime64[us, US/Eastern]')
There was a problem hiding this comment.
Also would be good to have a full smoke test from one of the 1D constructors e.g. pd.array('2022-01-01', dtype='datetime64[us, US/Eastern]')
would prefer to hold off; there's a check in DTA._simple_new that i haven't yet updated to handle non-nano dt64tz, so that'll get a dedicated (small) PR that makes a good fit for what you're suggesting
| num = 101 | ||
| base = np.dtype("M8[ns]") | ||
| base = np.dtype("M8[ns]") # TODO: depend on reso? |
There was a problem hiding this comment.
If base is analogous to "default" I think M8[ns] is a reasonable default.
There was a problem hiding this comment.
agreed but not clear thats what 'base' means. would be good to have that documented somewhere.
The alternative (that ive put together for (Timestamp|Timedelta).(min|max|resolution)) is a property-like that assumes nanoseconds when accessed on the class and is instance-specific when accessed on an instance
* ENH: DatetimeTZDtype support non-nano * mypy fixup * mypy fixup * TST: Day not supported
doc/source/whatsnew/vX.X.X.rstfile if fixing a bug or adding a new feature.