DOC: Correct inconsistent description on default DateOffset setting
correct inconsistent doc description on default DateOffset setting

- [x] closes #36512 

Also heads up there are linting issues
```
##[error]doc/source/user_guide/timeseries.rst:834:83:E501:line too long (105 > 79 characters)
```
to be resolved before merge why fail and how can I fix? What's wrong with "one calendar day"? ```
>>>ts = pd.Timestamp('2011-3-27 00:00:00', tz='Europe/Helsinki')
```
One calendar day will get the result below.
```
>>>ts + pd.DateOffset(days=1)
Timestamp('2011-03-28 00:00:00+0300', tz='Europe/Helsinki')
```
But now the default action is add absolute 24 hours.
```
>>>ts + pd.DateOffset()
Timestamp('2011-03-28 01:00:00+0300', tz='Europe/Helsinki')
>>>ts + pd.DateOffset(hours=24)
Timestamp('2011-03-28 01:00:00+0300', tz='Europe/Helsinki')
``` Ah, thanks! So how can I fix these failings? Seems that I only change one line. They're unrelated, you'll probably need to merge upstream/master later But still a little strange about the default value, why not just set it a calendar day since the offset objects are specially designed for calendar duration rules? I think this should ideally default to calendar day instead 24 hours as well. This would require a deprecation cycle related to https://github.com/pandas-dev/pandas/issues/7418 that would deprecate all arguments that don't end with `s`.

Would you be interested in making that change instead @GYHHAHA?  I will take a try. Hello @GYHHAHA! 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:

* In the file [`pandas/tests/tslibs/test_liboffsets.py`](https://github.com/pandas-dev/pandas/blob/2399eb8d2f0b7ba252ae35aee1f74f44f6676c6b/pandas/tests/tslibs/test_liboffsets.py):

> [Line 172:1](https://github.com/pandas-dev/pandas/blob/2399eb8d2f0b7ba252ae35aee1f74f44f6676c6b/pandas/tests/tslibs/test_liboffsets.py#L172): [W293](https://duckduckgo.com/?q=pep8%20W293) blank line contains whitespace



##### Comment last updated at 2020-09-22 06:42:18 UTC For #7418, can we just convert any argument in `kwds_no_nanos` that end with s to the one with s? @jreback  Also since the `_determine_offset` doesn't handle the nanosecond or nanoseconds, thus here is a bug related to this.
```
>>>ts = pd.Timestamp('2020-1-1')
>>>ts + pd.DateOffset(nanoseconds=1000)
Timestamp('2020-01-02 00:00:00')
```
Caused by the default `offset = timedelta(1)` setting. @mroeschke  Ok, I will keep this in original form, and should I continue to change the "1 calendar day" to "24 hours" in the DOC?
1) Maybe a warning need to be added when use singular arguments.
2) I find in #7418 `ts.replace(pd.DateOffset(...))` is suggested, is this a good way to make these replacement actions?
3) The above-mentioned nanoseconds BUG needs a fix, but since this relates to the default setting, will it be troublesome to handle?

Thanks. @jreback @mroeschke   Yes I think for this PR, you can just make the documentation change.

You can follow up with another PR to deprecate the DateOffset arguments that do not end in  `s` if interested.

Also if you could submit a bug report with the nanosecond example, that'd be great. Here are also some problems.

DOC says "However, all DateOffset subclasses that are an hour or smaller (Hour, Minute, Second, Milli, Micro, Nano) behave like Timedelta and respect absolute time.".

But though `DateOffset(days=1)` indeed use a calendar day, still `offsets.Day(1)` use 24 absolute hours.

Is it necessary to keep this consistency?

Besides, in #36592 I suggest to add `replace` method for time-related replacement, but now I also think it may not be a good choice.

However, we can only use `ts + pd.DateOffset(day=5)` to change the absolute `year/day/hour/... ` use the singular form argument which will be deprecated (if we make this deprecation), thus how can we do this absolute time replacement by other offsets object? (like changing year to 2000 or day to 22 or month to 5)

Thanks! @mroeschke  See https://github.com/pandas-dev/pandas/issues/22864 about the `offsets.Day` consistency.

For absolute time changes, I think users should just stick to using `Timedelta` objects. `DateOffset` object should only operate with relative time changes. agree with jbrockmendel

> If we're talking reasonably long-term, I think we should get rid of the Tick classes entirely and use Timedelta in their place

It will be much more clear to only consider the relative time (day, week, month ,year, ...) for offsets and tick time (nano, ..., minute, hour, absolute day) for timedelta. This pull request is stale because it has been open for thirty days with no activity. Please update or respond to this comment if you're still interested in working on this. @mroeschke this lgtu? Thanks @GYHHAHA 