BUG: Timestamp retains frequency of input Timestamps

[mroeschke]

• closes pd.Timestamp(timestamp) looses freq #22311
• tests added / passed
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[pep8speaks]

Hello @mroeschke! Thanks for submitting the PR.

• There are no PEP8 issues in the file pandas/tests/scalar/timestamp/test_timestamp.py !

[jbrockmendel]

LGTM.

Do any of the other constructors lose freq? (Eg to_datetime)

[mroeschke]

to_datetime looks good on master:

In [1]: pd.to_datetime(pd.Timestamp('2010-08-08', freq='D')).freq
Out[1]: <Day>

DatetimeIndex looks like it drops the frequency (but I am not sure if it should be kept in this case?)

In [3]: pd.DatetimeIndex([pd.Timestamp('2010-08-08', freq='D')]).freq

[jreback]

don't do this as could have an adverse perf impact (this is a python object). use is_offset_object

[jbrockmendel]

What do we expect it to be in this case? Aside from None I guess

[mroeschke]

This can be a Timestamp in which we want to extract its frequency and pass along.

[jbrockmendel]

IIUC you're referring to ts_input being a Timestamp. I'm asking what freq is in this case. More specifically, anything other than None seems like it should be invalid. Or am I missing something?

[mroeschke]

Ah sorry for misunderstanding. You're correct in that this is essentially swallowing any nonsense frequency and just returning None

[mroeschke]

freq should only ever be None, a offset string, or offset object

[toobaz]

Won't this silently pass if freq has invalid type? Couldn't we just say that freq = getattr(ts_input, 'freq', None) if freq is None else freq?

[codecov]

Codecov Report

Merging #23503 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master   #23503   +/-   ##
=======================================
  Coverage   92.25%   92.25%           
=======================================
  Files         161      161           
  Lines       51207    51207           
=======================================
  Hits        47239    47239           
  Misses       3968     3968

Flag	Coverage Δ
#multiple	90.63% <ø> (ø)	⬆️
#single	42.28% <ø> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 528527b...218e418. Read the comment docs.

[jreback]

lgtm. can you rebase and also do a quick perf check.

[mroeschke]

Looks like there's a little hit (I think the asvs make it seem worse than reality), but imo not too bad

$ asv continuous -f 1.1 upstream/master HEAD -b ^groupby

       before           after         ratio
     [d0691e05]       [2dcb1fbb]
+     1.29±0.04μs       2.21±0.6μs     1.71  timestamp.TimestampConstruction.time_parse_iso8601_no_tz
+     1.27±0.03μs       2.07±0.2μs     1.62  timestamp.TimestampConstruction.time_fromordinal
+     1.63±0.04μs       2.29±0.1μs     1.41  timestamp.TimestampConstruction.time_parse_today
+     1.59±0.01μs      2.22±0.06μs     1.40  timestamp.TimestampConstruction.time_parse_now
+      1.56±0.1μs       2.08±0.1μs     1.34  timestamp.TimestampConstruction.time_fromtimestamp

SOME BENCHMARKS HAVE CHANGED SIGNIFICANTLY.


# These two are the benchmark from timestamp.TimestampConstruction.time_parse_iso8601_no_tz
--branch
In [1]: %timeit pd.Timestamp('2017-08-25 08:16:14')
1.62 µs ± 42.1 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

--master
In [1]: %timeit pd.Timestamp('2017-08-25 08:16:14')
1.12 µs ± 13.4 ns per loop (mean ± std. dev. of 7 runs, 1000000 loops each)

[jreback]

thanks @mroeschke