First of all, a big thank you to everyone who responded to this one. I
doubt I'd have figured it out for days without your guidance and help.
And the winner is.... the JVM timezone. But the problem was NOT that
the JVM wasn't set to US Central time. The problem was that it WAS set
to US Central, apparently inherited from the Linux OS TZ. There was no
parameter on the tomcat java command that set the timezone. So I added
one and set it to America/Chicago. No change. But since it appeared we
were already double-dipping and converting from GMT to central twice
(i.e. subtracting an additional 6 hours), I figured ok.... tell the JVM
to stay in GMT and not do any conversions. So now, the database returns
Central time dates and times, but JVM no longer thinks it needs to
convert again to 'more central'.
This is about as convoluted and ugly as it gets. And I don't make any
claims of thinking I can give a rational explanation for why it works
this way. But it's on to fight a battle on another hill now.
Just to summarize for anybody who comes along with a similar problem....
I original set the timezone of mySQL RDS instance to Central time when I
created it months back (unchangable after it's set). I set my Linux
timezone to Central as well in order to make my log files have entries
with the correct timestamps. But as I described earlier, changing the
OS timezone made the JVM also go to Central as well. But the JVM
apparently assumed the database was in GMT so it subtracted 6 more hours
off the already-central time from the db. I guess the real error was
not initially leaving the MySQL RDS in GMT. But since that's not
changeable without recreating a whole new RDS instance, the next option
is what I did with the jvm. Makes total sense, right??? :-)
Thanks again.
Jerry
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
