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. > > > >
