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 <guettliml@thomas-guettler.de> 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