Timestamp.min and .max return a Python datetime object that is not a valid Timestamp

[SleepingPills]

import pandas as pd

pd.Timestamp(pd.Timestamp.min)

Throws: ValueError: Out of bounds nanosecond timestamp: 1-01-01 00:00:00

Pandas version: 0.11.1_dev
Numpy version: 1.7.1

The the min and max methods on the Timestamp class return simple Python datetime objects, but more importantly they do not adhere to the limitations of Timestamps. They return the default datetime(1,1,1) and datetime(9999, 12, 31, 23, 59, 59, 999999) respectively - both of which are well outside of the valid Timestamp range.

[jreback]

This is an inherited method

1. should this return a Timestamp object (rather than a datetime)
2. should it then conform to the Timestamp limitiations

if 1) then 2) is required

In [25]: 'min' in pd.Timestamp.__dict__
Out[25]: False

In [26]: pd.Timestamp.__mro__
Out[26]: 
(pandas.tslib.Timestamp,
 pandas.tslib._Timestamp,
 datetime.datetime,
 datetime.date,
 object)

In [28]: 'min' in datetime.datetime.__dict__
Out[28]: True

[jreback]

I am never used datetime.min/max what would you use them for?

[cpcloud]

@SleepingPills usually in case where you think u might want datetime min and max u usually want the idxmin/max of the series or frame that has a datetime index...

[SleepingPills]

I understand that they behave in this way because it is a method defined on datetime, but it just seems unintuitive that those functions are available on Timestamp but do not return a valid Timestamp at all. If they end up being used (to whatever purpose) they will likely cause subtle issues in indices or as column values (either turning into a NaT or the index/column being of dtype object).

IMO it would be nice if they were overridden and at least warned the user of potential pitfalls. I think that the best solution would be that they return a valid Timestamp and adhere to the timestamp limitations. There is still room for subtle problems (e.g. datetime.min != timestamp.min), but perhaps less so than currently.

If the general opinion is that these functions should not be used on a Timestamp at all, then I would override them and make them raise an error. Currently the intentions are anything but explicit or clear.

[jreback]

@SleepingPills

What does one actually use these values for?

its pretty easy to have it return the min/max supported for Timestamp (that's prob what we should do)

[SleepingPills]

I stumbled upon this by random chance - I just looked at the min/max on Timestamp and realized that they do not return what I'd expect them to.

As for usages:

One might use them to validate incoming data and ensure that they fall into the valid interval. I suppose one could just try to construct the Timestamp and catch the resulting error (which then needs to be interrogated on why actually the construction failed).

Another use case might be when dealing with datasets going back beyond the 17th century (the current lower boundary), where one might want to use as much data as can be fitted into Timestamps and can then query the source with Timestamp.min?

Admittedly, I can't come up with a single golden scenario where this functionality is absolutely required.

[jreback]

ok....seems reasonable.....you want to do a PR for this?

[SleepingPills]

Sure, I'll submit one shortly.

[jreback]

closed by #3902