On 1/7/2020 6:53 PM, Jerry Malcolm wrote:
>> If your systems always use the same time zone to read and write the
data, it isn't a problem.
Terrance, thanks for the info. In my case I do only have one timezone
(or at least I want to...). Using the string for dates is a good
idea. But this is a massive application that's been in production for
years with tons of date and timestamp fields spread everywhere across
the code and the db. So converting to strings is not a possibility now.
It still comes down to the fact that the mysql command line on my
linux box gets the date right, but it's converted incorrectly by JDBC
and only on the linux box (and works on WIndows)
When I first set up the box an installed Tomcat, the default Linux
time was gmt. I didn't change the Linux time to central until later.
Any chance that tomcat stored the timezone in effect when it was
installed and still is using that even though I changed the linux
timezone? (Just grasping at straws here).
Hi, Jerry-
I realize you've found an apparent work-around for the issue but, to be
clear, I did not use character columns. The column types were
DATETIME. However, when I inserted or updated, I provided string values
(e.g. update MyTable set myDateTime = '2020-01-08 06:57:00'). And, when
I read the data, I extracted date/time values from the result set using
getString (e.g. parseSqlDateTime( resultSet.getString( "myDateTime" ) ).
Best regards.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
