Anthony Tuininga

This issue was corrected in version 2.3.0, which was just released.

I strongly suspect this is because of corrupted data stored in your database. Try this: ```python import oracledb conn = oracledb.connect("user/password@host:port/service_name") cursor = conn.cursor() cursor.execute(""" select to_date('4712-01-01', 'YYYY-MM-DD'), dump(to_date('4712-01-01', 'YYYY-MM-DD'))...

The time portion defaults to 0 so adding that doesn't make any difference. :-) You can see that the output is identical. Run `dump()` on the date in your database...

> It does look like a bug to me. Let's see what is actually stored in the database, first.

Ok. I realized that the output didn't quite match, so I did this instead. Create a table and populate it with the hard-coded value: ```sql create table issue_345 ( date_val...

The other clients may have worked around this data corruption and python-oracledb can do the same, if that is the case. I will check internally to see if this is...

Ok, I tried inserting the date as follows: ```sql insert into issue_345 values (to_date('-4712-01-01', 'SYYYY-MM-DD')) ``` and then I get the error you mentioned. So I will have that corrected!

I have pushed a patch that corrects this issue. If you are able to [build from source](https://python-oracledb.readthedocs.io/en/latest/user_guide/installation.html#installing-from-source-code) you can verify that it works for you, too. NOTE: you will now...

> with cx_Oracle package, I am able to make it work using "outputtypehandler" feature but it does not work in Oracledb. It does not even go to DateTimeConverter function. What...

What you may be running into is the fact that thick mode performs the conversion from DATE to STRING internally in the Oracle Client libraries whereas thin mode always converts...