-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Terence,

On 1/7/20 7:33 PM, Terence M. Bandoian wrote:
> 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

Only for TIMESTAMP columns, which are fairly rarely used. Usually, you
want a DATETIME field, which is a SQL standard.

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

I've never had the intestinal fortitude to change the time zone on a
running MySQL server. So I'm not sure if it would shift every DATETIME
value I've ever written to it. Yikes, I'm using local time. I hope I
remember that for every server I ever migrate to.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VJrMACgkQHPApP6U8
pFgfyhAAu4jR5+hzu9oJJX9yN2rDeVw+3yGmHsiBF6eAZPUh7BLUkVV+kuhVxC+X
pqWAvgStzyUAt/L7mdxNbNhyDSBMn5WJgjenQ70eLTqg+u3PYtkB/S+zxDgfwRbN
x5WOzj/N1ypapdXCOZu7JnkmyL9tLQ1F+KfRIXPE9L6phlg4kDDvfvn9CGn+L/ir
YkWtDk6YcNiWo4tguYj3lXNQ68CGBM2gkYKjWVtNKO1Keit8w/GgHbXnm9QmzEX8
jeXAL1LO4kUVEZayfaEmaLaSVfltR6ROB1Ubx4KNMG777wy9ln0odP1KSdWcmq+u
Fu5kdsB25B+pxym0tPA21xIieGUp/4txCQn5WX66aLVS8CDgrWnl0uSP8iatZmPO
wKL6i4qCEfPXYNTzB+CcLBuiK/8PXqcnp3YO2Xj2nqvh4pqqmkCUgJBM5umQVmhR
7iH3T1LjWhOPEBUx50Vz7+Dd7yj4Z6CZ/ubRYXTWXmUifu8hO2d1YehYj0ean+3r
LaiTsmOHH9Tw1RDn+Wae4TCS+YEZZMLytSF2HnvXko87b/pU6eguapbO1ScBUepv
KFhAUWUAzPtdvf2aZhveVscLCFGR1+Jl3Zv31qjSSriPuB3shRpWa2Q+g0/KPwrl
zw3NiPsaIWL5hvxKdBllOKCMqoI7BwDlTkNocqb0QbHrYB5qcoA=
=ETH9
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to