On 08.01.20 06:05, Jerry Malcolm wrote: > 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??? :-)
That's why my personal general recommendation is to run all server code and OS, and especially all stored data, in UTC only. Optionally, for selected output (e.g. website display) have the application explicitly convert to a timezone, dependent on the current user (see Christopher's excellent answer). It's work, but it's what needs to be done. There is no "it just works" when handling time without being explicit - especially in the web / server world, where people access from different timezones. Desktop applications can be more relaxed (but shouldn't). Granted, it's easier for me with UTC being one or two hours off during the year, but the advantage is: UTC is "forward only" - there's no daylight saving back and forth, no need to interpret anything, just the plain timestamp. On the technical side (logs) that's what I want, even if it requires a bit of mental math. I'm not always remembering to set all of this right away, but it's the first thing I retroactively do once I run into those problems. Olaf --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
