SqlTimestampConverter Timezone UTC

[Maze-fr]

Hello,

I got a problem with the fact that SqlTimestampConverter forces its time zone to UTC.
It makes me loose my time zone specificity, so the hour I got is not the good one.

As I use XStream to send my objects to M$ SqlServer, it inserts / updates the time with what I sent, so not the good one...
I tried with ISO8601SqlTimestampConverter, but M$ SqlServer is unable to parse the string to timestamp, so the stored procedure fails.

I had to extends SqlTimestampConverter so I could override "format" field (using reflection) with the good time zone value : "getDefault()".

It would be very convenient to be able to change the time zone with a specific constructor with the time zone as parameter.

Greetings.

[joehni]

What do you mean by "use XStream to send my objects to M$ SqlServer"? Did you simply use XStream's converters? What type has the row in MS SQL?

Actually UTC is on purpose. If you persist a timestamp in XML, you will expect to get the same timestamp back, independently if it is deserialized with different daylight saving or even in another timezone.

[Maze-fr]

I have M$ SqlServer 2005 as database, and in order to have a simple way to manage updates and inserts, I use XStream to convert my Java objects into XML that I send to my stored procedure for use with syntax "OPENXML(some parameters) WITH My_Table". With that syntax, the mapping is done between my XML and My_Table columns automatically.

The problematic DB column type is "datetime", so I use "java.sql.Timestamp" to get it.
When I user "ISO8601SqlTimestampConverter", the DB don't manage to convert it to "datetime".
When I user "SqlTimestampConverter", UTC time is sent and my DB put it in a non UTC "datetime" (as it looks like) column, so I loose my time zone specification.

With 2008 version or early, I would use "datetimeoffset" column type and I wouldn't have any problem, but... well... bad luck, it is 4 years they are saying they want to upgrade to 2012 version, and now they started everything back saying they want to upgrade to 2014 version...

I thought about dealing with it in the stored procedure, but I have data transfers between different schemas through Java in XML strings (I know, it sucks ; don't ask why...) and "datetimes" don't need to be modified in that case. So I must generate XML with time zoned "timestamps" to keep it working properly.

I understand that UTC is on purpose, and I really think it's the good choice, as default.
But we should have the choice for those who work in a client environment where other people don't know how (or want) to do things well, and you have to deal with it...