Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Infinite dates handling: Better solution #283

Closed
guettli opened this issue Jan 26, 2015 · 6 comments
Closed

Infinite dates handling: Better solution #283

guettli opened this issue Jan 26, 2015 · 6 comments

Comments

@guettli
Copy link

guettli commented Jan 26, 2015

Better handling of infinite date handling:

Current state:
http://initd.org/psycopg/docs/usage.html#infinite-dates-handling
{{{
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.
}}}

It would be very good to have a better solution.

Feature Request: Support the special values from postgres:

  • infinity
  • - infinity

Related: http://www.postgresql.org/docs/current/static/datatype-datetime.html#AEN6027

I know that Python does not support infinty in the datetime module.

Maybe psycopg could use a custom subclass of date/datetime/timedelta?

@dvarrazzo
Copy link
Member

It is a nice idea for some aspects but for others it could create unexpected side effects. I'm thinking to programs where your date from the database is used in arithmetic with other dates instantiated from other sources. Would they work ok?

Something more aggressive would be monkeypatching the datetime module instead so that the entire Python process would use the provided extension. However not everybody is a monkeypatch fan. I'm not even sure the way datetime objects are used from C extensions would be affected by monkeypatching.

I think the best option is for this work not to be done by psycopg. What you can have instead is an external Python module, let's call it datetimeinf, that you could import and use objects from, optionally monkeypatch the system, optionally interface it to psycopg via its normal adaptation system.

So, while I don't think psycopg is the right place for these extended objects, I'll leave this proposal open if you or someone else wanted to put it together. I won't work on this project now though: it's up to you.

@guettli
Copy link
Author

guettli commented Feb 3, 2015

Just of the records. I asked on the mailing list python-ideas if datetime could be improved to support infinity. There was positive feedback: http://code.activestate.com/lists/python-ideas/31288/

@dvarrazzo
Copy link
Member

If Python gained an infinite datetime representation of course psycopg would use it. Of course don't expect it for Python <= 3.6.

@guettli
Copy link
Author

guettli commented Feb 4, 2015

I hope there will be backport. Example: subprocess32 has the nice timeout parameter for Python 2.x. Stdlib is not as important as it was.

@dvarrazzo
Copy link
Member

If any Python version will start supporting infinite dates we will handle them accordingly. Please keep us informed.

@guettli
Copy link
Author

guettli commented Mar 31, 2015

I asked on python-ideas again:

https://groups.google.com/d/msg/python-ideas/JqZltloYEBw/KcNYVKQnzqsJ

{{{
any progress on infinite datetimes?

I just got the commitment from psycopg2 (lib to connect to PostgreSQL) developers,
that they will support them, if python would:

#283 (comment)

I can't help you with code in this context.

I have never started a crowd funding campaign. Do you think it would
be successful?
}}}

@psycopg psycopg locked and limited conversation to collaborators Jun 16, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

2 participants