-
-
Notifications
You must be signed in to change notification settings - Fork 18.7k
Closed
Labels
API - ConsistencyInternal Consistency of API/BehaviorInternal Consistency of API/BehaviorDatetimeDatetime data dtypeDatetime data dtypeReshapingConcat, Merge/Join, Stack/Unstack, ExplodeConcat, Merge/Join, Stack/Unstack, ExplodeTimezonesTimezone data dtypeTimezone data dtype
Milestone
Metadata
Metadata
Assignees
Labels
API - ConsistencyInternal Consistency of API/BehaviorInternal Consistency of API/BehaviorDatetimeDatetime data dtypeDatetime data dtypeReshapingConcat, Merge/Join, Stack/Unstack, ExplodeConcat, Merge/Join, Stack/Unstack, ExplodeTimezonesTimezone data dtypeTimezone data dtype
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
jorisvandenbossche commentedon Jan 22, 2021
This is a bit related to #37605 ? If we decide there (for setitem) that matching tzawareness (but not tz-equality) is enough, then I would expect also both
union
andjoin
to preserve a tzaware datetime dtype (which means casting to UTC, I suppose).jbrockmendel commentedon Jan 23, 2021
One way to implement this would be to make
find_common_type
for mismatched dt64tzs return UTC. Doing this would change the setop behavior in a pretty reasonable way. the sticking point is in a couple of groupby tests:In both of these examples, its pretty reasonable to think the user would want the object-dtype result
jorisvandenbossche commentedon Jan 29, 2021
I think for those two cases you bring up, it makes sense to have UTC tz-aware as output (AFAIU that's also what the original reporter wanted in #27496)