Is your feature request related to a problem? If so, please give a short summary of the problem and how the feature would resolve it

We have an application that uses SQL Server 2019 and the current schema uses datetime datatype for tracking timestamps. Since the database compatibility level is set to 2019, the JDBC driver is converting all timestamps into datetime2 datatypes which is causing a number of bugs in our application.

We are currently using a third party JDBC driver (Progress® DataDirect Connect® Series for JDBC™) which offers a DateTimeInputParameterType connection string which you can use on newer databases to have it declare parameters as datetime instead of datetimeoffset. However, we are soon planning on moving our application stack and want to use the Microsoft SQL Server Driver as it is officially support in the new application server we plan on using.

I would like to see a similar connection string added to the JDBC driver which would allow you to specify how the JDBC driver handlers timestamps without having to lower the compatibility level of the database.

Describe the preferred solution

Add a new connection string (e.g. timestampEncoding) which can be used to determine how timestamp should be encoded. For example, you might have the following options:

See #443 (comment)

Describe alternatives you've considered

Alternatives we've considered:

• Converting the schema to use datetime2. We will probably eventually do this, but in a large multi-tenant application stack this is going to take a lot of work. We have a lot of functionality driven by timestamps, so this refactoring will take time.
• Casting values to datetime. Timely to implement and would require another round of refactoring when we final do migrate to datetime2 values.
• Lowering the database compatibility level. Unfortunately, we are using some SQL Server 2017 functionality, so in order to do this we would need to remove this functionality. We would also lose query plan performance improvements implemented in newer versions of SQL Server.
• Forking the current code and using our fork. We'd like to avoid forking the code if possible, so we can stay on the official code path.

Additional context

none

Reference Documentations/Specifications

n/a