API: require timezone match in DatetimeArray.shift

[jbrockmendel]

• closes #xxxx
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[jreback]

i guess this is a small api change (e.g. what did this do before)?

can you add a whatsnew note (rebase as well)

[jorisvandenbossche]

@jbrockmendel what's the rationale of requiring matching timezone here? (as long as tz-awareness matches)

[jbrockmendel]

what's the rationale of requiring matching timezone here? (as long as tz-awareness matches)

Trying to have some consistency about which methods require matching tz vs just tzawareness-compat. The heuristic is to require matching tz for setitem-like methods.

[jorisvandenbossche]

Isn't that inconsisten with other operations like aritmetic/comparison ops, which allow it? (like the subtract PR that is also open)

Also setitem on Series doesn't actually raise, so on the Series level, those methods are also not fully consistent.

[jbrockmendel]

Isn't that inconsisten with other operations like aritmetic/comparison ops, which allow it? (like the subtract PR that is also open)

Right, those methods are not considered "setitem-like". searchsorted is also considered comparison-like as opposed to setitem-like.

Also setitem on Series doesn't actually raise, so on the Series level, those methods are also not fully consistent.

The Series is cast to object and the value being set is not cast to the existing timezone. DatetimeBlock._can_hold_element is equivalent to

def _can_hold_element(self, element):
    try:
        self.array_values()._validate_setitem_value(element)
        return True
    except TypeError:
        return False

[jreback]

Isn't that inconsisten with other operations like aritmetic/comparison ops, which allow it? (like the subtract PR that is also open)

Right, those methods are not considered "setitem-like". searchsorted is also considered comparison-like as opposed to setitem-like.

Also setitem on Series doesn't actually raise, so on the Series level, those methods are also not fully consistent.

The Series is cast to object and the value being set is not cast to the existing timezone. DatetimeBlock._can_hold_element is equivalent to

def _can_hold_element(self, element):
    try:
        self.array_values()._validate_setitem_value(element)
        return True
    except TypeError:
        return False

we should rationalize these one way or the other for all ops. I would be +1 on always being strict here, though this would break some existing code / tests.

[jbrockmendel]

we should rationalize these one way or the other for all ops. I would be +1 on always being strict here, though this would break some existing code / tests.

I'd be on board with being consistent across all these methods, but I think we would basically have to make it the non-strict version. Otherwise we would break consistency with the stdlib datetime on comparisons (xref #37329).

[jreback]

thanks @jbrockmendel

yeah I agree we need to make this consitent, but this PR itself is fine as its just requires a tz matching fill value.