[FEATURE REQUEST] Ability to explicitly specify conversion to datetime or datetime2

[dswitzer]

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:

Option	Description
DATETIMEOFFSET	always use DATETIMEOFFSET.
DATETIME2	always use DATETIME2. Good if the user knows they only use DATETIME2 datatypes in their schema (current behavior).
DATETIME	always use DATETIME (old behavior). Good if the user is dealing with a legacy schema and is not willing to upgrade.
QUERYDB	the new code, but not compatible with encrypted connections. Good for mixed schemas.

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

[dswitzer]

This was talked about in #443, but since the feature request was buried within the comments and a little different than the original problem, I thought a proper feature request made sense.

[lilgreenbird]

hi @dswitzer

Thanks for creating this feature request, I have filed this into our backlog it will be considered and prioritized along with other features when we plan for the next semester.

[dswitzer]

@lilgreenbird

Thanks for the update. Let me know if there's anything I can do to assist you with the request.

NOTE — I'd be content with just being able to specify datetime or datetime2. I realize the trying to autodetect the correct type is problematic, but it was from the original requestor. I get that mixed timestamp datatypes are going to be problematic.

[dswitzer]

@lilgreenbird

I have just created a pull request which adds this feature. Once I got into the code, I realized there's no way to support something like the querydb option.

What the pull request does is implement a datetimeParameterType that can used to control the data type to use when converting date/times to parameters. The default behavior is the same as the code today, which is that datetime2 is used. However, if you're supporting an older database that is only using datetime data types, but want to run the database in SQL Server 2016 compatibility level or higher, you can set this to datetime and all the date/time conversions from Java will be declared as datatime parameters removing any casting issues with how SQL Server handles casting datetime2 to datetime.

This is something sorely missing from the JDBC driver when supporting older databases.

There are many times an organization may be running a legacy database, but want to run the database in SQL Server 2016 compatibility mode to take advantage of the query optimizations. Today there's no way to that. This feature would allow support for databases using only datetime data types.

[ecki]

thanks a lot, we will review it and respond here.