@@ -2265,6 +2265,24 @@ you can use the ``tz_convert`` method.
2265
2265
Instead, the datetime needs to be localized using the ``localize `` method
2266
2266
on the ``pytz `` time zone object.
2267
2267
2268
+ .. warning ::
2269
+
2270
+ If you are using dates beyond 2038-01-18, due to current deficiencies
2271
+ in the underlying libraries caused by the year 2038 problem, daylight saving time (DST) adjustments
2272
+ to timezone aware dates will not be applied. If and when the underlying libraries are fixed,
2273
+ the DST transitions will be applied. It should be noted though, that time zone data for far future time zones
2274
+ are likely to be inaccurate, as they are simple extrapolations of the current set of (regularly revised) rules.
2275
+
2276
+ For example, for two dates that are in British Summer Time (and so would normally be GMT+1), both the following asserts evaluate as true:
2277
+
2278
+ .. ipython :: python
2279
+
2280
+ d_2037 = ' 2037-03-31T010101'
2281
+ d_2038 = ' 2038-03-31T010101'
2282
+ DST = ' Europe/London'
2283
+ assert pd.Timestamp(d_2037, tz = DST ) != pd.Timestamp(d_2037, tz = ' GMT' )
2284
+ assert pd.Timestamp(d_2038, tz = DST ) == pd.Timestamp(d_2038, tz = ' GMT' )
2285
+
2268
2286
Under the hood, all timestamps are stored in UTC. Values from a time zone aware
2269
2287
:class: `DatetimeIndex ` or :class: `Timestamp ` will have their fields (day, hour, minute, etc.)
2270
2288
localized to the time zone. However, timestamps with the same UTC value are
0 commit comments