DOC: timezone warning for DST beyond 2038-01-18
State: closed

Add warning to time_series user guide that after 2038-01-18 DST will not be respected in tz aware dates 

- [x ] closes #33061
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry


Labels:
name: Docs
name: Timezones
description: Timezone data dtype

Comments:
> If you are using dates beyond 18 Jan 2038, note that pandas does not apply daylight saving time adjustments to timezone aware dates. This is partly because the underlying libraries do not currently address the Year 2038 Problem, and partly because there is some discussion on how reliable any DST settings that far into the future will be.

As mentioned in the issue, I do not think this wording is accurate. `pandas` only ever uses the UTC offsets provided by the libraries. Right now the libraries that `pandas` supports do not have any transitions after 2038-01-18.

I think if you're going to warn against this, something more circumspect would be a good idea, like:

> Time zone data for far future time zones are likely to be inaccurate, as they are simple extrapolations of the current set of rules. In general, it is inadvisable to rely on the accuracy of time zone data for far future datetimes. This is especially true for datetimes after 18 January 2038, since some time zone libraries do not support transitions after that point due to the Year 2038 Problem.

I'm vague about the "some time zone libraries" since I know that `dateutil` is planning to add support soon-ish and the maintainer of `pytz` has said that he's intending to turn `pytz` into a thin wrapper around PEP 615 when it is available (and the PEP 615 `zoneinfo` module *does* support these), so it is likely that any strong wording here will become inaccurate soon.
Thanks for the response. I think we need to get the 2038 issue in there first, because that is the symptom users will see. Also, I didn't want to go into any details of the cause of version 1 libraries being used to store transition dates in signed 32-bit fields, as I wanted to keep it quite short - there are already 3 other warnings in that section of the guide!  I don't think people are that interested in where the cause of the issue is, as long as it will be fixed well before the epochalypse! (love that term!  probably reveals my tz naivety that I haven't heard it before) . 

Proposed new wording: 

If you are using dates beyond 2038-01-18, due to current deficiencies in the underlying libraries caused by the year 2038 problem, daylight saving time (DST) adjustments to timezone aware dates will not be applied. The underlying libraries will be fixed at some point, which will also correct this behaviour. It should be noted though, that time zone data for far future time zones are likely to be inaccurate, as they are simple extrapolations of the current set of (regularly revised) rules.
> The underlying libraries will be fixed at some point.

I think this guarantee is too strong. I think the phrasing should just imply that the fix is on the timezone library side.

If and when the underlying libraries are fixed, the DST transitions will be applied? 
Sure. If you could push up the revised changes, it will be easier to review inline from the changes than here in the comments.
thanks @telferm57 

happy to have clarifications in another PR. but this looks good for now.