On 1/7/2020 4:04 PM, Zahid Rahman wrote:
Jerry Malcolm wrote :
>Again this is the SAME line of code in java reading the >SAME field in
the SAME database. Only thing different is >Linux/Windows OS
On Tue, 7 Jan 2020, 21:52 , <john.e.gr...@wellsfargo.com.invalid> wrote:
-----Original Message-----
From: Jerry Malcolm <techst...@malcolms.com>
Sent: Tuesday, January 07, 2020 3:14 PM
To: users@tomcat.apache.org
Subject: Re: Dates on Linux vs. Windows
On 1/7/2020 3:09 PM, Michael Osipov wrote:
Am 2020-01-07 um 21:58 schrieb Jerry Malcolm:
This may be more of a Java question than Tomcat. But I'm not sure. I
have the same code, talking to the same MySql Linux (AWS) database.
I read a date column value in a Tomcat app. After calling
resultSet.getDate(...) I printed the date instance and the getTime()
value:
On windows: 2019-02-01 1549000800000
On linux: 2019-01-31 1548979200000
Again this is the SAME line of code in java reading the SAME field in
the SAME database. Only thing different is Linux/Windows OS. The
date is supposed to be 2/1/2019 and shows that in phpMyAdmin.
I've been running on Linux for a few months. But I don't have an
extensive background in the specifics of Linux. I'm sure there must
be something that is configured differently. I'm at a loss. But this
is not a trivial problem. I do monthly billing. My dates need to be
accurate.
Have you verified that you aren't tricked by any timezone issues?
Probably so. But how would I know? I was under the impression that
java.sql.Date was timezone independent. Shouldn't it simply convert a
month/day/year value to the number of milliseconds since the epoch? How
would timezone issues affect that? And if I am 'tricked' how do I
'untrick'. What do I set/change?
Those millisecond values are 6 hours apart, which looks like a timezone
issue. I happen to be in US Central time, which is 6 hours earlier than
UTC in winter.
You're right that System.currentTimeMillis() itself is independent of
timezone but Date is not.
As I understand it, for certain date/time column types, MySQL subtracts
the time zone from the value when written and adds it back in when
read. If your systems always use the same time zone to read and write
the data, it isn't a problem. But it can be if the time zone varies.
See https://dev.mysql.com/doc/refman/5.7/en/datetime.html
The actual behavior is a little confusing, at least to me, because I
seem to remember variations in the storage of the date/time columns
while the documentation seems to indicate that date/time values are not
modified. Also, if I remember correctly, writing a date/time value as a
formatted string and then reading it back as a string (e.g.
ResultSet.getString) and parsing it circumvented the time zone issue.
Hope that helps.
-Terence Bandoian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
