On Sun, Oct 11, 2015 at 8:38 PM, Stephan Hoyer <sho...@gmail.com> wrote:
> Currently, NaT (not a time) does not have any special treatment when used > in comparison with datetime64/timedelta64 objects. > > To me, this seems a little crazy for a value meant to denote a > missing/invalid time -- NaT should really have the same comparison behavior > as NaN. > Yes, indeed. > Whether you call this an API change or a bug fix is somewhat of a judgment > call, but I believe this change is certainly consistent with the goals of > datetime64. It's also consistent with how NaT is used in pandas, which uses > its own wrappers around datetime64 precisely to fix these sorts of issues. > Getting closer to Pandas is a Good Thing too... > So I'm raising this here to get some opinions on the right path forward: > 1. Is this a bug fix that we can backport to 1.10.x? > 2. Is this an API change that should wait until 1.11? > 3. Is this something where we need to start issuing warnings and deprecate > the existing behavior? > > My vote would be for option 2. > I agree. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
