Antoine Pitrou <solipsis@pitrou.net> 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