-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jerry,
On 1/7/20 7:03 PM, Jerry Malcolm wrote:
>
> On 1/7/2020 5:31 PM, calder wrote:
>> On Tue, Jan 7, 2020, 17:17 Jerry Malcolm <techst...@malcolms.com>
>> wrote:
>>
>>>> On Tue, 7 Jan 2020, 21:52 ,
>>>> <john.e.gr...@wellsfargo.com.invalid> wrote:
>> '. 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.
>>> That all makes sense. But at the end of the day, what do I do
>>> to make it work right? I am also in Central time. My Linux OS
>>> is set to central (at least I tried to set that. Afterwards my
>>> log entries are correctly logging in central time instead of
>>> gmt. So I assume it's set right). What do I need to do in
>>> Tomcat to 'fix' it so that sql dates aren't somehow adjusted?
>>> I simply want a 2019-02-01 in the database to appear as
>>> 2019-02-01 in java. And the same code must work identically on
>>> both OS's.
>>>
>>
>> Have you checked the DST setting?
>
> I googled around trying to see how to check DST in Amazon Linux.
> the Date command gave me the correct date and timezone with no DST
> which is currently correct. I looked at the /etc/sysconfig/clock
> file. It has two lines:
>
> ZONE="CST6ST" UTC=true
>
> But DST is only one hour change. An earlier post said that my two
> different values of times were 6 hours off. Would DST be the cause
> of that?
Welcome to the wonderful world of civil date-reckoning.
First off: you have the correct date. You just aren't holding it
correctly[1].
Second, where are you showing this date? In a log somewhere? How are
you printing it?
If you are using java.sql.Date.toString(), then it should probably be
telling you the TZ. If you are using SimpleDateFormat then you need to
be aware that both java.util.Date (the surprising superclass of
java.sql.Date, which doesn't have a time portion!) and
SimpleDateFormat have their own TimeZone settings. And, for fun, there
is no SimpleDateFormat constructor which takes a TimeZone argument.
And, for more fun, java.util.Date doesn't have a TimeZone... it's got
a (primitive) long offset in milliseconds. And a DST offset. Which is
separate. Confused, yet?
So you pretty much always need to do this:
SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd");
df.setTimeZone(TimeZone.getTimeZone("America/Chicago"));
Date d = ... // whatever
logger.trace("Got date: " + df.format(d));
If you aren't showing the time zone, you can always become confused.
For example, if your Date object has an offset in UTC and your
SimpleDateFormat is in US-CST, you can get different *days* depending
upon the time of day represented by the Date object.
It's a mess.
The only way to do it is to always always ALWAYS handle the time zone
properly.
If you are using java.sql.Date which should be yyyy-MM-dd *only*, then
you may have to truncate the time and/or adjust to e.g. UTC and maybe
even do both of those so that you never accidentally cross the
international date-line when interpreting your dates.
But the good news is that only the humans will be confused by these
dates. Generally speaking, the database and Java are doing things
correctly.
Unless you are accepting input.
Whenever you ask a user to enter a date (or, worse, a date-time), you
need to read their input *in their timezone*, since, well, that's how
they think. It's 19:38 local time for me, but for someone in London
it's 01:38 *tomorrow*. So if I ask them for the current datetime, they
will say 2020-01-08T01:38:00. If I don't interpret that as being in UK
Winter Time, then I might think that the timestamp represents
2020-01-08T01:38:00 CST. Or maybe whatever the default time zone is
for your EC2 instance. Or your JVM. Or for the user who actually
launched your JVM. This time.
So do yourself a favor and fix all your date-manipulation code so it's
always doing the right thing. It may take a while, but it will be Correc
t.
Everybody has to go through this at some point. Good luck.
Oh, and just so you don't feel like you bet on the wrong horse, this
isn't just a Java thing. It's the same with all languages. Java was
written in a quaint time when they thought that java.util.Date would
do everything necessary. Until java.util.Calendar came along. And then
Jodatime. And then java.time.*. If you look at most other languages,
there are similar progressions with vestigial leftovers that still
work, and are littered all over all the APIs.
- -chris
[1] https://knowyourmeme.com/memes/events/iphone-4-death-grip
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VJZ4ACgkQHPApP6U8
pFgnIQ//S3S/K34K80fQN4nhgzdFBlVEcko+tiDBD5GR2e3Tt0BJ36nF6v9D+p3o
Y37JRaMiU4T2SaMWXREs2rNID+UmZXsfB3Cfgvub+vFqGZiXeEUm2KMv8KS1NYER
goPZ0aSuRqKibIjzqKws/OWuYQzU7YBre44hwXmiRX7lppUOaEiSH2eH/zYC0tFZ
j8WSk79a7nJoTX0iHZfHMcBu8hgy7bZD9FqEbug/typ+ZRueMvaWgQzhUU8HRV28
8nY62PxO6wEr8MMxS7V+CkQbibvlv/g1HgT841gLEUry93jzOciIqIc+G8b1WF4b
ghDeASnD/H2zNwQPT0VRS5+Jg3U+RzbPJmHyjPowhNZP8gGcvA2zBovEUPy3R0EB
VC86Zy0EAmkSuAG/eP3wGoY1r+zRTEi0KHl9LaWPUFJyv5gPhqGYYpLq+Ge9B+K/
cxZoBixO6Ldvo4Tx6AIgRdZqTOu3TPLqVd18gkRHuY7Jl/aM/JfxgYRlZrQXk/cE
8VWGIyzD0VY0xkmLAcFLIC9ScNYuSq4nBfgCyFCBFaSrHneBl40X+8fkf92HMJTo
jfO2xkeQ98Axl+2CGIynvS6tcm+zELmQMBPZazsCI6uldR6N3L9W2bqsy9BckP5Q
u13UnBCHkzflIPt0DCr0DwU/UoqgtslIqWVA1AuGNVRBrKbH1Lc=
=gy4I
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
