Don't think about converting or adapting time zone. Don't think about the TZ the mysql uses to store your timestamps or anythink like that. Those things are already handled.
There are three things that you must handle: INPUT, OUTPUT and bugs.
When a user enters a date (in a form) without an explicit time zone you have to know what TZ did he intend to use. You can use a SimpleDateFormat object with time zone set to solve this. You don't have to convert the input date, you have to 'interpret' it correctly. Once you have a correctly interpreted Date or timestamp you are done with input.
Input is not only user input, includes configuration files too.
The same here. Forget about what TZ have your Date objects and timestamps have none, they are just milliseconds since epoch. You have to format your dates to the TZ the user expects so he understand them.
You may have bugs in your code related to TZ, but libraries may have them too!!
I noticed mysql java driver failed to communicate the client timezone to the server.
This command s.executeUpdate ("set time_zone='+xx:yy'"); is the workaround but you are using it wrong. You have to tell the server with it the TZ the client is using, before both inserting and querying. The variable is stored in the session. Maybe you may automatize it on your connection pool config.
This is needed so the server know what TZ the client need to use to read or write. This is not dependent on server TZ. It does not mean "store this date in UTC", it does mean "this date I am giving to you is UTC" and "Send me result sets in UTC". No matter you are using Date class with it's internal TZ, the driver screws it up, you would need to set that session variable.
By default it assumes client TZ is the same as server TZ so you shouldn't need to worry about it as you said they are the same.
This is bad advice. SQL dates in general (and mysql in specific) are stored as year/month/.../sec fields, not millis since the epoch. Time zones are relevant for the conversion to Java dates, and only "handled" for you if you want the default behavior, which OP does not. For non-trivial applications, you do need to think about time zones, at both the server storage level and conversion steps, or you may encounter subtle bugs.
@AndrewJanke If the server can give you the dates in any time zone why do you need to store them in a certain time zone? The only risk to avoid is thinking one date has a certain TZ being wrong. I don't see the point on working with 'string dates' with a specific time zones but to read/write from/to the user. I develop SCADA systems used and configured by users on different time zones and simply work with jave.util.Date objects or timestamps without any TZ problem.
You need to be concerned with what time zone you store them in on the server to avoid ambiguities in time zone conversion. For time zones which use daylight saving time, certain wall times like "2:00 AM" can occur twice on "fall back" days, and there's not enough information in the SQL date to disambiguate them. And if you don't have known, consistent, non-ambiguous time zones, server-side date arithmetic may be wrong.
@AndrewJanke Well. That's broken in mysql. stackoverflow.com/questions/1646171/ I guess you need to use UTC on server, as we do.
It's not just broken on MySQL, it's a common issue with many SQL RDBMSes, and any other data store that can store dates in naive "local" times without additional DST indicators. Which means yes, you have to think about how the server is storing the dates. Running your server in UTC is a good fix for this (I run mine in UTC too for this reason). But as OP stated, is not an option for them.