On Mon, Jan 26, 2015 at 10:14:23AM +0100, Antoine Pitrou wrote:

On Mon, 26 Jan 2015 09:24:07 +0100 Thomas Güttler wrote:

...

PostgreSQL can store the representation of an “infinite” date, timestamp, or interval. Infinite dates are not available to Python, so these objects are mapped to date.max, datetime.max, interval.max. Unfortunately the mapping cannot be bidirectional so these dates will be stored back into the database with their values, such as 9999-12-31.

Unless someone has a real-world use for the values of date.max, datetime.max, interval.max, I find it rather counter-productive to not store them back as infinities.

That would make them de-facto infinities that weirdly don't look like infinities: py> datetime.date.max datetime.date(9999, 12, 31) If I'm reading this page correctly, PostgreSQL supports a lot of dates that Python doesn't, up to 5874897AD: http://www.postgresql.org/docs/9.4/static/datatype-datetime.html so it might not matter if 9999-12-31 gets turned into infinity rather than treated as a normal date.

Adding infinities to the datetime module would probably be possible but someone has to figure out the arithmetic rules. Do we need "not a time" when adding infinity to -infinity?

I shouldn't think so. The purpose of NANs in IEEE-754 maths is to allow the programmer to delay dealing with the failed operation until the end of the calculation. I don't think that date calculations tend to be anywhere as complicated as mathematical ones, so it would be acceptable to just raise an exception. Besides, Postgresql doesn't have a "NotATime" value, so if we're trying to match what they do, we don't need one either. -- Steven

On Mon, Jan 26, 2015, at 06:44, Steven D'Aprano wrote:

If I'm reading this page correctly, PostgreSQL supports a lot of dates that Python doesn't, up to 5874897AD:

Why doesn't Python support these? You know, as long as we're talking about expanding the range of datetime.

Antoine Pitrou writes:

Unless someone has a real-world use for the values of date.max, datetime.max, interval.max, I find it rather counter-productive to not store them back as infinities.

The values are useful to know exactly how far in the future one can store date values in Python. It is important that this be discoverable programmatically because the maximum values might change in future versions of the ‘datetime’ library. Because it remains true (and presumably will continue to be true) that the maximum value is *not* infinity, it is important that the following real-world cases are distinct: * Query the ‘datetime’ library for the largest (furthest-in-the-future) value that it can handle. * Store a value explicitly meaning “infinitely far in the future” or “infinitely far in the past” compared to any actual date or datetime value. I have needed both, sometimes in the same program. An example is to be able to represent the timestamp field of a journal entry that is still being composed and has not yet gained a timestamp. ‘None’ is not sufficient, because it must be “in the future” compared to any actual point in time, even greater than ‘datetime.date.max’. To use the same value attempting to represent both “maximum” and “infinite” is a fragile, and needlessly confusing, hack. Having distinct “infinitely far in the future” and “infinitely far in the past” values, that are *not* themselves particular points on the timeline, would be a valuable addition for this reason.

Adding infinities to the datetime module would probably be possible but someone has to figure out the arithmetic rules. Do we need "not a time" when adding infinity to -infinity?

Adding dates (or datetimes) is not a valid operation today, so I don't see why we would need to change behaviour there. -- \ “This world in arms is not spending money alone. It is spending | `\ the sweat of its laborers, the genius of its scientists, the | _o__) hopes of its children.” —Dwight Eisenhower, 1953-04-16 | Ben Finney

On Tue, Jan 27, 2015 at 5:47 PM, Antoine Pitrou wrote:

...

Adding dates (or datetimes) is not a valid operation today, so I don't see why we would need to change behaviour there.

We're talking about both datetimes and timestamps here. Please follow.

I think Antoine meant "timedeltas". Having a date infinity necessitates an infinite timedelta to represent a difference between a finite and an infinite date. While we cannot add dates, it is still a valid question what the result of subtracting an infinite date from itself should be. If we make it timedelta(0) then date.inf is not that different from date.max.

On Tue, Jan 27, 2015 at 05:59:13PM -0500, Alexander Belopolsky wrote:

On Tue, Jan 27, 2015 at 5:47 PM, Antoine Pitrou wrote:

...

...

Adding dates (or datetimes) is not a valid operation today, so I don't see why we would need to change behaviour there.

We're talking about both datetimes and timestamps here. Please follow.

I think Antoine meant "timedeltas". Having a date infinity necessitates an infinite timedelta to represent a difference between a finite and an infinite date.

While we cannot add dates, it is still a valid question what the result of subtracting an infinite date from itself should be. If we make it timedelta(0) then date.inf is not that different from date.max.

The obvious question is "What does Postgresql do?" Same for use-cases, which Antoine asked for. The primary use-case is to improve compatibility with Postgresql while still treating the full range of dates up to and including date.max as regular dates. I'm not convinced that numpy is the right library to follow here. Unless there are cases where you would perform calculations with Not-A-Time, an exception would probably be better suited. -- Steve

Antoine Pitrou writes:

On Wed, 28 Jan 2015 09:42:16 +1100 Ben Finney wrote:

...

The [minimum and maximum] values are useful to know exactly how far in the future [and past] one can store date values in Python. It is important that this be discoverable programmatically because the maximum [or minimum] values might change in future versions of the ‘datetime’ library.

So what? Again, the values wouldn't change in Python. It would only be the PostgreSQL mapping that would change.

That's the point, though. We should at least allow for “datetime.date.max” and “datetime.date.infinitely_far_in_the_future” to be distinct, and allow for the former to change value in a backward-compatible way. So the maxima and minima should map to their specific points in time in both directions between PostgreSQL and Python. “Maximum” does not mean “infinite”, and conflating them robs us not only of the backward-compatible ability to change the maximum in future, but also of the ability to later add a distinct value to represent infinity. -- \ “You don't need a book of any description to help you have some | `\ kind of moral awareness.” —Dr. Francesca Stavrakoloulou, bible | _o__) scholar, 2011-05-08 | Ben Finney

Hi, On 2015-01-27 18:04, Chris Barker wrote:

On Tue, Jan 27, 2015 at 2:47 PM, Antoine Pitrou wrote: [...]

> > Adding infinities to the datetime module would probably be > > possible but > > someone has to figure out the arithmetic rules. Do we need > > "not a time" > > when adding infinity to -infinity?

not_a_timedelta, I suppose, or simply disallow it.

But if you do allow it -- then following the rules for floating point inf, -inf, and NaN would make sense.

Adding datetime.neg_inf() and datetime.pos_inf() should return datetime.now(). Regards, Yawar

On Tue, Jan 27, 2015 at 7:29 PM, Yawar Amin wrote:

On 2015-01-26 11:31, Chris Barker - NOAA Federal wrote:

...

I have a sample implementation if anyone wants to look at it, though I don't think it does reflected comparisons correctly. it's really only just good enough for our use case.

I'd like to take a look. Can you send it to me, or post it somewhere?

Sure, here you go: https://github.com/NOAA-ORR-ERD/PyGnome/blob/master/py_gnome/gnome/utilities... -Chris -- 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.Barker@noaa.gov

On Wed, Jan 28, 2015 at 6:55 PM, Yawar Amin wrote:

Cool, the comparison operator logic looks very similar to mine:

https://groups.google.com/d/msg/python-ideas/G3jeWoa6h14/ELpDLFu28QcJ

Did you get it to work both ways? i.e. datetime.neg_inf < datetime.now() and datetime.now() > datetime.neg_inf I had trouble with that, because the regular datetime doesn't know how to compare itself to a neg_inf object.

I believe the ideal design is the following type hierarchy:

datetime_base datetime_neg_inf datetime_pos_inf datetime

But in the interests of pragmatism, I think this one can be made to work:

datetime datetime_neg_inf datetime_pos_inf

yup -- should work. and you could add class methods to the datetime object, so you could do: datetime.neg_inf() and datetime.pos_inf()

The

advantage to this is that we don't have to switch everything over to

using a new derived type--just use the normal datetime for the majority of cases where we don't need inifinity dates.

And it could be a third part package, too. -- particularly good for backward compatibility. -Chris -- 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.Barker@noaa.gov

On Thu, Jan 29, 2015 at 10:10 AM, wrote:

Works fine on python 3.3.

Good.

Python 2 raises exception from __lt__,

yeah, that's what I got -- we're on 2 for now. You'd think there wold be a way to do it -- but I don't see a "reflected" versions of the comparison operators. But for anything new, it'd be in 3.5+ anyway, so sounds like we're good. Though it would be nice to have it as a recipe for older versions. -Chris -- 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.Barker@noaa.gov

On Thu, Jan 29, 2015 at 11:14 AM, Ethan Furman wrote:

...

...

Python 2 raises exception from __lt__,

yeah, that's what I got -- we're on 2 for now. You'd think there wold be a way to do it -- but I don't see a "reflected" versions of the comparison operators.

Raising an exception was a bug. The comparison operators are their own reflection.

So does that mean it could be fixed in 2.* ? (or already has been?) -Chris -- 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.Barker@noaa.gov

On Thu, Jan 29, 2015, at 14:14, Ethan Furman wrote:

On 01/29/2015 11:09 AM, Chris Barker wrote:

...

On Thu, Jan 29, 2015 at 10:10 AM, random832 wrote:

...

Python 2 raises exception from __lt__,

yeah, that's what I got -- we're on 2 for now. You'd think there wold be a way to do it -- but I don't see a "reflected" versions of the comparison operators.

Raising an exception was a bug. The comparison operators are their own reflection.

Or, more precisely, they are *each other's* reflection (__gt__ being the reflection of __lt__). This works fine in 2.7 for types that properly return NotImplemented. This is just a bug in Python 2's datetime module.

Hi Chris, sorry for the top-posting; replying from my phone. My test implementation works for me on Python 2.7, see http://repl.it/9Wz Notice especially the last few assertions, where normal datetime objects are on the LHS. Regards, Yawar On 2015-01-29, at 2:04, Chris Barker wrote:

On Wed, Jan 28, 2015 at 6:55 PM, Yawar Amin wrote:

...

Cool, the comparison operator logic looks very similar to mine:

https://groups.google.com/d/msg/python-ideas/G3jeWoa6h14/ELpDLFu28QcJ

Did you get it to work both ways? i.e.

datetime.neg_inf < datetime.now()

and

datetime.now() > datetime.neg_inf

I had trouble with that, because the regular datetime doesn't know how to compare itself to a neg_inf object.

...

I believe the ideal design is the following type hierarchy:

datetime_base datetime_neg_inf datetime_pos_inf datetime

But in the interests of pragmatism, I think this one can be made to work:

datetime datetime_neg_inf datetime_pos_inf

yup -- should work.

and you could add class methods to the datetime object, so you could do:

datetime.neg_inf() and datetime.pos_inf()

...

The advantage to this is that we don't have to switch everything over to using a new derived type--just use the normal datetime for the majority of cases where we don't need inifinity dates.

And it could be a third part package, too. -- particularly good for backward compatibility.

-Chris

--

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.Barker@noaa.gov

On 01/29/2015 11:29 AM, random832@fastmail.us wrote:

On Thu, Jan 29, 2015, at 14:19, Yawar Amin wrote:

...

Hi Chris, sorry for the top-posting; replying from my phone.

My test implementation works for me on Python 2.7, see http://repl.it/9Wz

Notice especially the last few assertions, where normal datetime objects are on the LHS.

How'd you do that? Does python always know to use the derived class's operators when working with a base class and a derived class?

I can't find the reference, but yes. So the broken datetime behavior would only be noticed by a non-datetime derived class. -- ~Ethan~

On Thu, Jan 29, 2015 at 11:19 AM, Yawar Amin wrote:

My test implementation works for me on Python 2.7, see http://repl.it/9Wz

cool site! And yes, it does appear to work. However the subclassing approach is really weird, as the infinite datetimes have a year, month, day, etc -- that strikes me as ripe for error. That's why I didn't subclass, but just had them e independent. Another option would be to override just about everything... -Chris

Notice especially the last few assertions, where normal datetime objects are on the LHS.

Regards,

Yawar

On 2015-01-29, at 2:04, Chris Barker wrote:

On Wed, Jan 28, 2015 at 6:55 PM, Yawar Amin wrote:

...

Cool, the comparison operator logic looks very similar to mine:

https://groups.google.com/d/msg/python-ideas/G3jeWoa6h14/ELpDLFu28QcJ

Did you get it to work both ways? i.e.

datetime.neg_inf < datetime.now()

and

datetime.now() > datetime.neg_inf

I had trouble with that, because the regular datetime doesn't know how to compare itself to a neg_inf object.

...

I believe the ideal design is the following type hierarchy:

datetime_base datetime_neg_inf datetime_pos_inf datetime

But in the interests of pragmatism, I think this one can be made to work:

datetime datetime_neg_inf datetime_pos_inf

yup -- should work.

and you could add class methods to the datetime object, so you could do:

datetime.neg_inf() and datetime.pos_inf()

...

The

advantage to this is that we don't have to switch everything over to

...

using a new derived type--just use the normal datetime for the majority of cases where we don't need inifinity dates.

And it could be a third part package, too. -- particularly good for backward compatibility.

-Chris

--

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.Barker@noaa.gov

-- 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.Barker@noaa.gov