Fix for parsing timestamp field in Oracle

Thanks for the patch. It's indeed Oracle specific and would break other jdbc libraries. That's why I'm not going to include your patch. I've already planned but not fully implemented another optional parameter for the connect method that would allow you to specify a mapping that's specific to your database. Something similar to this:

def your_ora_todatetime(java_val):
    java_val = java_val.toJdbc()
    d = datetime.datetime.strptime(str(java_val)[:19], "%Y-%m-%d %H:%M:%S")
    if not isinstance(java_val, basestring):
        d = d.replace(microsecond=int(str(java_val.getNanos())[:6]))
    return str(d)

conn = connect('oracle.jdbc.OracleDriver', ['jdbc:oracle:thin:@//foo:1521/bar'], converters=dict(TIMESTAMP=your_ora_todatetime))

I'll try to implement this in the next couple of weeks if I find the time. Most of the code is already there. I think I'll include your sample implementation in the documentation.

Thank you!

Since all we are doing here is converting Oracle specific data to a standardized jdbc data, we would normally just need:

def your_ora_todatetime(java_val):
    java_val = java_val.toJdbc()
    return _todatetime(java_val)

Would it make sense to instead give users an option to "filter" driver specific data to jdbc standard?

e.g.
conn = connect('oracle.jdbc.OracleDriver', ['jdbc:oracle:thin:@//foo:1521/bar'],
                              jdbc_converters=dict(TIMESTAMP=lambda x: x.toJdbc()))

If fact, since we know this driver specific issue, we may have this map in the dbapi2 module itself:
     jdbc_converters = {
                                         'oracle.jdbc.OracleDriver': {
                                                               'TIMESTAMP': lambda x: x.toJdbc()
                                                            }
                                       }

Your converter logic can then check if there is an additional jdbc converter required for a specific driver before doing the usual processing.

Thanks for the idea. I'll keep that in mind. My first thought is that I don't want to start keeping db-specific stuff in my code because I don't want to modify it for every db. Imagine that there might be cases where you use the same driver class name but have different driver versions or databases that act differently for the types. So it would soon get too complicated.

On the other hand it would be nice to have a tool that is able to deal with every databse without much tinkering.

Feel free to play branch JayDeBeApi. If you found a cool solution I would love to merge you stuff :) Anyway, I'll try to address this issue in some way when I find time.

Just to let you know: It should be fixed in https://github.com/baztian/jaydebeapi/tree/feature/improve-types-support. Would appreciate feedback in https://github.com/baztian/jaydebeapi/issues/3