-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jerry,
On 1/9/20 1:15 PM, Christopher Schultz wrote:
> You should write yourself some small tests in Java to try
> everything [you've] read here. Just grab a date value from the
> database and inspect the object you get back. Mess with the time
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jerry,
On 1/8/20 6:24 PM, Jerry Malcolm wrote:
>
> On 1/8/2020 4:47 PM, Christopher Schultz wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>> Johan,
>>
>> On 1/8/20 3:28 AM, Johan Compagner wrote:
>>> So you moved once the database
On 1/8/2020 4:47 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Johan,
On 1/8/20 3:28 AM, Johan Compagner wrote:
So you moved once the database to a different timezone (that had
say that 6 hour difference) then the behavior is correct...
Its very weird but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Johan,
On 1/8/20 3:28 AM, Johan Compagner wrote:
> So you moved once the database to a different timezone (that had
> say that 6 hour difference) then the behavior is correct...
>
> Its very weird but that is default behavior of the normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Jerry,
On 1/8/20 12:05 AM, Jerry Malcolm wrote:
> 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.
Glad you are all set, though I'm not sure I agree
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
>From my past experience with dates and timestamps, it helps to pass the
time zone as a jvm parameter when starting tomcat
-Duser.timezone=Europe/London
On Wed, 8 Jan 2020 at 05:05, Jerry Malcolm wrote:
> First of all, a big thank you to everyone who responded to this one. I
> doubt I'd
So you moved once the database to a different timezone (that had say that 6
hour difference)
then the behavior is correct...
Its very weird but that is default behavior of the normal datetime columns
that are created if you move stuff around the database somehow remembers at
what timezone the
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
