ENH: Use tz-aware dtype for timestamp columns #263
Conversation
tswast
force-pushed
the
issue261-tzaware-dtype
branch
from
3e442e8 to
b0445ca
Compare
|
Looks like we'll have to bump the minimum version to |
I couldn't figure out how *not* to get a tz-aware dtype in 0.24.x versions, and I wanted a tz-aware dtype anyway for TIMESTAMP, so this makes it official.
tswast
force-pushed
the
issue261-tzaware-dtype
branch
from
b0445ca to
e1c2df4
Compare
| DATETIME datetime64[ns] | ||
| TIME datetime64[ns] | ||
| DATE datetime64[ns] | ||
| ================== ========================= |
tswast
force-pushed
the
issue261-tzaware-dtype
branch
from
afe40c2 to
2a1c422
Compare
…eTZDtype as numpy dtype.
tswast
force-pushed
the
issue261-tzaware-dtype
branch
from
2a1c422 to
c76dbba
Compare
This is the first version that passing a dtype of pandas.api.types.DatetimeTZDtype(tz="UTC") to the Series constructor actually works. I get "TypeError: data type not understood" in lower versions.
|
Oof. Looks like I still get the occasional @max-sixty Thoughts on bumping the minimum version all the way to 0.24? It's a big jump from what we've had before. Otherwise, I'll see if I can make our tests robust against having naive datetime in 0.23 and before. |
tswast
force-pushed
the
issue261-tzaware-dtype
branch
from
4601721 to
a5a11ab
Compare
tswast
added
the
do not merge
|
I'm going to branch this PR with just the docs changes. I'd rather not bump all the way to 0.24.0 just yet. |
|
Closing in favor of #269. As was pointed out to me in pandas-dev/pandas#25843 (comment) it's more "idiomatic" to call localize rather than be specific about timezones in the dtype. I'd prefer to avoid additional casts / localization if at all possible, so just documenting the current behavior for now. |
I couldn't figure out how not to get a tz-aware dtype in 0.24.x
versions, and I wanted a tz-aware dtype anyway for TIMESTAMP, so this
makes it official.
Towards #261.