FIX BUG: Timestamp __add__/__sub__ DateOffset with nanoseconds lost.
- [x] closes #43892
- [x] tests added / passed
- [x] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit) for how to run them
- [x] whatsnew entry

Hey guys, not only `Timestamp.__add__(DateOffset)`, but also `Timestamp.__sub__(DateOffset)` not works. Should I fix the `__sub__` method in this PR or should I open another PR? Thanks~ > Should I fix the __sub__ method in this PR or should I open another PR

Doing it in the same PR is fine > this needs tests

I am going to put some tests later. Found another bug: the `DateOffset(nanoseconds=1)` object is not constructed correctly.
```Python
from pandas.tseries.offsets import DateOffset

print(DateOffset(nanoseconds=1)._offset.__repr__())

# datetime.timedelta(1)
```
Which should be "datetime.timedelta(0)". Hello @tushushu! Thanks for updating this PR. We checked the lines you've touched for [PEP 8](https://www.python.org/dev/peps/pep-0008) issues, and found:



There are currently no PEP 8 issues detected in this Pull Request. Cheers! :beers: 

##### Comment last updated at 2021-12-17 11:21:13 UTC @jbrockmendel @jreback 
`DateOffset` object can accept both `nanoseconds` and `nanosecond` as parameters at the same time, does this make sense? It also happens with `day` and `days`, `second` and `seconds`, `microsecond` and `microseconds`...

```Python
>>> DateOffset(nanoseconds=1, nanosecond=1).__dict__
{'_offset': datetime.timedelta(1), '_use_relativedelta': False, 'nanoseconds': 1, 'nanosecond': 1}

>>> DateOffset(microsecond=1, microseconds=1).__dict__
{'_offset': relativedelta(microseconds=+1, microsecond=1), '_use_relativedelta': True, 'microsecond': 1, 'microseconds': 1}

>>> DateOffset(second=1, seconds=1).__dict__
{'_offset': relativedelta(seconds=+1, second=1), '_use_relativedelta': True, 'second': 1, 'seconds': 1}

>>> DateOffset(day=1, days=1).__dict__
{'_offset': relativedelta(days=+1, day=1), '_use_relativedelta': True, 'day': 1, 'days': 1}
``` > DateOffset object can accept both nanoseconds and nanosecond as parameters at the same time, does this make sense? It also happens with day and days, second and seconds, microsecond and microseconds

Yes, this is following the behavior of dateutil's relativedelta So this branch can make `DataOffset`  `__add__` or `__sub__` a timestamp correctly when it has a `nanoseconds` attribute, and the questions you guys had are answered. Shall we go forward to merge this PR? Do you still have some concerns?

For the behavior of having `nanoseconds` and `nanosecond` at the same time, maybe we could create another PR to discuss. What do you guys suggest? @jbrockmendel @jreback  @tushushu comments still above > @tushushu comments still above

Hey @jreback , for some unknown reason, some comments do not show in this page. Would you please click this link https://github.com/pandas-dev/pandas/pull/43968/files/37d19b54a87c1b2e210a52f7607e94b48a06b990 or the `view changes` button, and then respond to my and @jbrockmendel 's comments? actually @tushushu can you add a whatsnew note and ping on green. bugfix for 1.4 in the datetime section is good. will take a fresh look (Thursday morning) > actually @tushushu can you add a whatsnew note and ping on green. bugfix for 1.4 in the datetime section is good.

It's done. Please take a look, thanks~ @jbrockmendel over to you, merge when ready hmm tests seems to be failing, can you merge master. these don't seem related, but it is possible something changed. yah i think merging master should fix most/all of the CI complaints After merging the master PR to current, the previous tests passed, but got a new one 
```
'Hypothesis test_where_inplace_casting(data=[None, None, -4399835, -5869]) produces unreliable results: 
Falsified on the first call but did not on a subsequent one
``` hmm lots of things are failing I accidentally deleted a colon -_- hmm something must have changed recently as https://github.com/pandas-dev/pandas/runs/4457135516?check_suite_focus=true are failing and look related actually @tushushu these are failing elsewhere so nothing to do rn. will have you rebase once this is ironed out. @tushushu the py310 failures were also unrelated, have now been fixed.  one more rebase pls. > @tushushu the py310 failures were also unrelated, have now been fixed. one more rebase pls.

Let me have a try~ thanks @tushushu for sticking with this! Thanks @jreback and @jbrockmendel for reviewing this PR.