Time zone issue with log4j

[Toby G]

This is a real puzzle.
I have two Union installations (and a test version of each on my own PC).
All of them run fine.

Summary of the problem:

The log timestamps are different from one installation to the other.

In one case, log timestamps are standard time, one hour behind DST. (this is what I'd like to change)
In the other, log timestamps reflect DST.

Can anyone identify with either side of this and mention what versions of software they are using?
Or provide any clues about how to solve this mystery?


I have read a few posts on stackoverflow.com where people say log4j has this
bug, and that it is fixed in version 2.8.something.  It appears there are enough
differences that using that version is not practical (it's not possible to change
any logging calls in the Union code, for example).
Also, it would be difficult to downgrade the one that's a little ahead of the other.

But if log4j has a bug, why is it showing up in one case but not the other?
That's the real mystery.

Lots of details follow:

A) has STANDARD time timestamps:

Ubuntu 16.04 LTS (GNU/Linux 2.6.32-042stab127.2 x86_64)
Union 2.1.1
Java version "1.7.0_95"
OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-3)
OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode)

B) has DST timestamps

 Ubuntu 14.04.1 LTS (GNU/Linux 2.6.32-042stab123.9 x86_64)
Union 2.1.1
 java version "1.7.0_131"
OpenJDK Runtime Environment (IcedTea 2.6.9) (7u131-2.6.9-0ubuntu0.14.04.2)
OpenJDK 64-Bit Server VM (build 24.131-b00, mixed mode)

Both of them have the system time zone set to US Eastern time,
and both use log4j version 1.2.17

On the PC test versions, one of which is 2.0.0 and the other is 2.1.2 the timestamps reflect DST.
There, the Java version is even older, 1.7.0_40.

I know, what a bizarre mix of old software versions - that's what happens when you create things in different years.

[Toby G]

Even weirder:

I tried out Java 8 on the system that had the time zone issue (log times in standard instead of daylight savings time).

When I was using Java 8, that bug went away!
Log entries reflected DST.

But since I was having runaway memory usage issues, I reverted to Java 7,
and then I noticed there were log entries out of time sequence -
apparently, but not really.  It was just the time zone bug returning to life.

2018-07-28 02:49:51,375 WARN  - UNION SHUTDOWN  (using Java 8)
2018-07-28 01:51:09,588 WARN  - ***********************************************
2018-07-28 01:51:09,589 WARN  - *** Starting Union Server 2.1.1 (build 600) *** (using Java 7)

This is now  back to Java 1.7.0_95.  I should try to get that 131 release somewhere.

[Toby]

A few more details:

On Ubuntu 14, you get a later version of Java 7 (build 131) which has the bug fixed.
On Ubuntu 16, oddly, you get an earlier version of Java 7 (build 95) in which the bug is not fixed.

On 14, I have Java 8 version 171, and on 16, I have version 181, neither of which exhibits the bug.
(It's possible that I simply got those at different times, and there was an update in between.)

[Toby]

In order to get a different Java version for the system where I was using Ubuntu 16,
failing any other way, I decided to change the operating system.

I tried CentOS and that went nowhere - websockets weren't working, among other things.

I then tried Debian, and chose blindly Debian 8 rather than Debian 9.
Debian and Ubuntu are quite similar and Debian 8 looks a lot like Ubuntu 14.
The Java 7 I installed (see my other thread here about memory usage for why)
is called "(IcedTea 2.6.14) (7u181-2.6.14-2~deb8u1)" and I will find out
if the DST problem persists in March when the clocks change.
I anticipate that it will not.

[saul diaz]

Hey @toby

we use java-1.8.0-openjdk-headless-1.8.0.191.b12-1.el7_6.x86_64 in centos 7 no issues..

[Toby]

Thanks for your reply.

I don't know enough about the differences between Unix distributions to prefer one or another,
so Debian 8 is fine by me - it allows me to have a Java update which fixes the dates problem.

I simply could not use Java 8 because its memory footprint just
keeps growing, seemingly without bounds, and Java 7 does not.

I could not determine the source of the leak, although I believe
it is connected to using Union accounts for logins.

It is also possible that my own code is the source of the leak,
but for now, it is easier to stick with Java 7 than try to figure
that all out.