We need to know the version of the stubs that you have installed and a more complete example that runs.

To find the version of the stubs within VS Code, use this code

from pandas._version import _stub_version

Then in VS Code, put your mouse over _stub_version and it will show the version.

We need to know the version of the stubs that you have installed and a more complete example that runs.

Can reproduce on main:

import datetime
from pandas.tseries.offsets import BDay

datetime.date(2023, 1, 1) + BDay(2)
datetime.date(2023, 1, 1) - BDay(2)
reveal_type(BDay(2) + datetime.date(2023, 1, 1)) # datetime.date but pd.Timestamp at runtime

I was using pylance to check types and the date + BDay stubs seems to be incorrect

Technically it is correct because pd.Timestamp is a sub-class issubclass(pd.Timestamp, datetime.date) but it could be more precise :) Returning the correct sub-class may require many overloads, as there are many combinations (date/Timestamp/Tick/Day/BDay/...).

Thanks for confirming!
Doesn't it always return pd.Timestamp or an offset though? (and offset is not subclass of datetime.date)
Quickly cross-checking the examples you've mentioned I don't see any new cases where it could result in different, python-native types.

Your are welcome to open a PR, the relevant file is https://github.com/pandas-dev/pandas-stubs/blob/main/pandas-stubs/_libs/tslibs/offsets.pyi It is best to make changes and run the CI (poe test) to see whether the runtime and typing behavior agree :)

I think the line def __add__(self, other: _DatetimeT) -> _DatetimeT: ... is definitely wrong, an improvement may be def __add__(self, other: datetime.date) -> pd.Timestamp: ... even if that is not always the case.