You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/source/timeseries.rst
+100-37
Original file line number
Diff line number
Diff line change
@@ -358,8 +358,8 @@ See :ref:`here <timeseries.oob>` for ways to represent data outside these bound.
358
358
359
359
.. _timeseries.datetimeindex:
360
360
361
-
DatetimeIndex
362
-
-------------
361
+
Indexing
362
+
--------
363
363
364
364
One of the main uses for ``DatetimeIndex`` is as an index for pandas objects.
365
365
The ``DatetimeIndex`` class contains many timeseries related optimizations:
@@ -399,8 +399,8 @@ intelligent functionality like selection, slicing, etc.
399
399
400
400
.. _timeseries.partialindexing:
401
401
402
-
DatetimeIndex Partial String Indexing
403
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
402
+
Partial String Indexing
403
+
~~~~~~~~~~~~~~~~~~~~~~~
404
404
405
405
You can pass in dates and strings that parse to dates as indexing parameters:
406
406
@@ -457,22 +457,6 @@ We are stopping on the included end-point as it is part of the index
457
457
458
458
dft['2013-1-15':'2013-1-15 12:30:00']
459
459
460
-
.. warning::
461
-
462
-
The following selection will raise a ``KeyError``; otherwise this selection methodology
463
-
would be inconsistent with other selection methods in pandas (as this is not a *slice*, nor does it
464
-
resolve to one)
465
-
466
-
.. code-block:: python
467
-
468
-
dft['2013-1-15 12:30:00']
469
-
470
-
To select a single row, use ``.loc``
471
-
472
-
.. ipython:: python
473
-
474
-
dft.loc['2013-1-15 12:30:00']
475
-
476
460
.. versionadded:: 0.18.0
477
461
478
462
DatetimeIndex Partial String Indexing also works on DataFrames with a ``MultiIndex``. For example:
@@ -491,12 +475,86 @@ DatetimeIndex Partial String Indexing also works on DataFrames with a ``MultiInd
491
475
dft2 = dft2.swaplevel(0, 1).sort_index()
492
476
dft2.loc[idx[:, '2013-01-05'], :]
493
477
494
-
Datetime Indexing
495
-
~~~~~~~~~~~~~~~~~
478
+
.. _timeseries.slice_vs_exact_match:
479
+
480
+
Slice vs. exact match
481
+
~~~~~~~~~~~~~~~~~~~~~
482
+
483
+
.. versionchanged:: 0.20.0
484
+
485
+
The same string used as an indexing parameter can be treated either as a slice or as an exact match depending on the resolution of an index. If the string is less accurate than the index, it will be treated as a slice, otherwise as an exact match.
486
+
487
+
For example, let us consider ``Series`` object which index has minute resolution.
488
+
489
+
.. ipython:: python
490
+
491
+
series_minute = pd.Series([1, 2, 3],
492
+
pd.DatetimeIndex(['2011-12-31 23:59:00',
493
+
'2012-01-01 00:00:00',
494
+
'2012-01-01 00:02:00']))
495
+
series_minute.index.resolution
496
+
497
+
A Timestamp string less accurate than a minute gives a ``Series`` object.
498
+
499
+
.. ipython:: python
500
+
501
+
series_minute['2011-12-31 23']
502
+
503
+
A Timestamp string with minute resolution (or more accurate), gives a scalar instead, i.e. it is not casted to a slice.
504
+
505
+
.. ipython:: python
506
+
507
+
series_minute['2011-12-31 23:59']
508
+
series_minute['2011-12-31 23:59:00']
509
+
510
+
If index resolution is second, then, the minute-accurate timestamp gives a ``Series``.
496
511
497
-
Indexing a ``DateTimeIndex`` with a partial string depends on the "accuracy" of the period, in other words how specific the interval is in relation to the frequency of the index. In contrast, indexing with datetime objects is exact, because the objects have exact meaning. These also follow the semantics of *including both endpoints*.
512
+
.. ipython:: python
513
+
514
+
series_second = pd.Series([1, 2, 3],
515
+
pd.DatetimeIndex(['2011-12-31 23:59:59',
516
+
'2012-01-01 00:00:00',
517
+
'2012-01-01 00:00:01']))
518
+
series_second.index.resolution
519
+
series_second['2011-12-31 23:59']
520
+
521
+
If the timestamp string is treated as a slice, it can be used to index ``DataFrame`` with ``[]`` as well.
However if the string is treated as an exact match the selection in ``DataFrame``'s ``[]`` will be column-wise and not row-wise, see :ref:`Indexing Basics <indexing.basics>`. For example ``dft_minute['2011-12-31 23:59']`` will raise ``KeyError`` as ``'2012-12-31 23:59'`` has the same resolution as index and there is no column with such name:
533
+
534
+
To select a single row, use ``.loc``.
535
+
536
+
.. ipython:: python
537
+
538
+
dft_minute.loc['2011-12-31 23:59']
539
+
540
+
Note also that ``DatetimeIndex`` resolution cannot be less precise than day.
498
541
499
-
These ``datetime`` objects are specific ``hours, minutes,`` and ``seconds`` even though they were not explicitly specified (they are ``0``).
542
+
.. ipython:: python
543
+
544
+
series_monthly = pd.Series([1, 2, 3],
545
+
pd.DatetimeIndex(['2011-12',
546
+
'2012-01',
547
+
'2012-02']))
548
+
series_monthly.index.resolution
549
+
series_monthly['2011-12'] # returns Series
550
+
551
+
552
+
Exact Indexing
553
+
~~~~~~~~~~~~~~
554
+
555
+
As discussed in previous section, indexing a ``DateTimeIndex`` with a partial string depends on the "accuracy" of the period, in other words how specific the interval is in relation to the resolution of the index. In contrast, indexing with ``Timestamp`` or ``datetime`` objects is exact, because the objects have exact meaning. These also follow the semantics of *including both endpoints*.
556
+
557
+
These ``Timestamp`` and ``datetime`` objects have exact ``hours, minutes,`` and ``seconds``, even though they were not explicitly specified (they are ``0``).
500
558
501
559
.. ipython:: python
502
560
@@ -525,10 +583,10 @@ regularity will result in a ``DatetimeIndex`` (but frequency is lost):
525
583
526
584
ts[[0, 2, 6]].index
527
585
528
-
.. _timeseries.offsets:
586
+
.. _timeseries.components:
529
587
530
588
Time/Date Components
531
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~
589
+
--------------------
532
590
533
591
There are several time/date properties that one can access from ``Timestamp`` or a collection of timestamps like a ``DateTimeIndex``.
534
592
@@ -564,6 +622,8 @@ There are several time/date properties that one can access from ``Timestamp`` or
564
622
565
623
Furthermore, if you have a ``Series`` with datetimelike values, then you can access these properties via the ``.dt`` accessor, see the :ref:`docs <basics.dt_accessors>`
566
624
625
+
.. _timeseries.offsets:
626
+
567
627
DateOffset objects
568
628
------------------
569
629
@@ -628,12 +688,12 @@ We could have done the same thing with ``DateOffset``:
628
688
629
689
The key features of a ``DateOffset`` object are:
630
690
631
-
- it can be added / subtracted to/from a datetime object to obtain a
632
-
shifted date
633
-
- it can be multiplied by an integer (positive or negative) so that the
634
-
increment will be applied multiple times
635
-
- it has ``rollforward`` and ``rollback`` methods for moving a date forward
636
-
or backward to the next or previous "offset date"
691
+
- it can be added / subtracted to/from a datetime object to obtain a
692
+
shifted date
693
+
- it can be multiplied by an integer (positive or negative) so that the
694
+
increment will be applied multiple times
695
+
- it has ``rollforward`` and ``rollback`` methods for moving a date forward
696
+
or backward to the next or previous "offset date"
637
697
638
698
Subclasses of ``DateOffset`` define the ``apply`` function which dictates
639
699
custom date increment logic, such as adding business days:
@@ -745,7 +805,7 @@ used exactly like a ``Timedelta`` - see the
745
805
746
806
Note that some offsets (such as ``BQuarterEnd``) do not have a
747
807
vectorized implementation. They can still be used but may
748
-
calculate significantly slower and will raise a ``PerformanceWarning``
808
+
calculate significantly slower and will show a ``PerformanceWarning``
749
809
750
810
.. ipython:: python
751
811
:okwarning:
@@ -755,8 +815,8 @@ calculate significantly slower and will raise a ``PerformanceWarning``
755
815
756
816
.. _timeseries.custombusinessdays:
757
817
758
-
Custom Business Days (Experimental)
759
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
818
+
Custom Business Days
819
+
~~~~~~~~~~~~~~~~~~~~
760
820
761
821
The ``CDay`` or ``CustomBusinessDay`` class provides a parametric
762
822
``BusinessDay`` class which can be used to create customized business day
@@ -785,7 +845,7 @@ Let's map to the weekday names
785
845
786
846
pd.Series(dts.weekday, dts).map(pd.Series('Mon Tue Wed Thu Fri Sat Sun'.split()))
787
847
788
-
As of v0.14 holiday calendars can be used to provide the list of holidays. See the
848
+
Holiday calendars can be used to provide the list of holidays. See the
789
849
:ref:`holiday calendar<timeseries.holiday>` section for more information.
790
850
791
851
.. ipython:: python
@@ -1289,12 +1349,15 @@ limited to, financial applications.
1289
1349
See some :ref:`cookbook examples <cookbook.resample>` for some advanced strategies
1290
1350
1291
1351
Starting in version 0.18.1, the ``resample()`` function can be used directly from
1292
-
DataFrameGroupBy objects, see the :ref:`groupby docs <groupby.transform.window_resample>`.
1352
+
``DataFrameGroupBy`` objects, see the :ref:`groupby docs <groupby.transform.window_resample>`.
1293
1353
1294
1354
.. note::
1295
1355
1296
1356
``.resample()`` is similar to using a ``.rolling()`` operation with a time-based offset, see a discussion :ref:`here <stats.moments.ts-versus-resampling>`
Copy file name to clipboardExpand all lines: doc/source/whatsnew/v0.20.0.txt
+31-3
Original file line number
Diff line number
Diff line change
@@ -193,14 +193,42 @@ in prior versions of pandas) (:issue:`11915`).
193
193
194
194
.. _whatsnew_0200.api:
195
195
196
+
Other API Changes
197
+
^^^^^^^^^^^^^^^^^
198
+
196
199
- ``CParserError`` has been renamed to ``ParserError`` in ``pd.read_csv`` and will be removed in the future (:issue:`12665`)
197
200
- ``SparseArray.cumsum()`` and ``SparseSeries.cumsum()`` will now always return ``SparseArray`` and ``SparseSeries`` respectively (:issue:`12855`)
201
+
- :ref:`DatetimeIndex Partial String Indexing <timeseries.partialindexing>` now works as exact match provided that string resolution coincides with index resolution, including a case when both are seconds (:issue:`14826`). See :ref:`Slice vs. Exact Match <timeseries.slice_vs_exact_match>` for details.
0 commit comments