<div dir="ltr"><div>Thanks for starting this discussion, Brock!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 29 May 2020 at 21:03, Tom Augspurger <<a href="mailto:tom.augspurger88@gmail.com">tom.augspurger88@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 29, 2020 at 11:37 AM Brock Mendel <<a href="mailto:jbrockmendel@gmail.com" target="_blank">jbrockmendel@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div>We could then consider de-duplication. Tick is already redundant with Timedelta, and Timestamp[H] would render Period[H] redundant.  With appropriate deprecation cycle, we could rip out a bunch of code.</div></div></blockquote><div><br></div><div>What would the user facing changes that warrant deprecation? For me, `Period` represents a span of time. It would make sense to implement something like `pd.Timestamp("2000-01-01") in pd.Period("2000-01-01", freq="H")`. But something checking whether that timestamp is in a `Timestamp[H]` doesn't seem natural, since it represents a point in time rather than a span.<br></div><div> </div></div></div></blockquote><div></div><div>Personally, I don't think we necessarily need to add all units that are supported by numpy's datetime64/timedelta64 dtypes. First, because I don't think it is an important use case (people mostly want to be able to have dates outside of the range limits that nanosecond resolution gives us), and also because it makes it conceptually a lot more difficult. For example, what is a "Timestamp[H]" value? Does it represent the beginning or the end of the hour? That are questions that are already handled by the Period dtype, and I think it is a good thing to keep those concepts separated (you can of course ask the same question with a millisecond resolution, but I think generally people don't do that). <br></div><div>Further, all the resolutions from nanosecond up to second are "just" multiplications x1000, keeping the implementation more simple (compared to resolutions of hours, months, ..). <br></div><div><br></div><div>So for a timestamp dtype, we could maybe only support ns / µs / ms / s resolutions?<br></div><div> </div></div></div>