I am facing an unusual problem.
An application deploying in Production on Oracle WebLogic has started exhibiting a bug. Dates that should be printing out as, e.g., 24 Mar 00:00:00 EDT 2020 are printing out as 23 Mar 23:00:00 EST 2020.
The other WebLogic server logs, not from our application, are also printing in EST (Eastern Standard Time) instead of EDT (Eastern Daylight Time).
This is only happening in Production.
The timezone, which the application dumps to its log, is correct in all environments (i.e., "America/New_York"). I checked the $JRE_HOME/lib/tzdb.dat files in both environments and they are identical.
Does anyone know what might be causing this?
It’s a guess, but a fully consistent one. The dates and times that are printed with time zone abbreviation (EST or EDT) most probably use the JVM’s default time zone. So the setting of the default time zone has been changed in your production WebLogic server. Any program running in the server can do that. Even a program running outside WebLogic in the same JVM can if there is one. At any time.
The default time zone is set from the system property user.timezone on startup (or the first time a program in the JVM does anything with a time zone, I am not sure). Changing the JVM’s default time zone later on does not work back on the system property. For a brief demonstration:
System.setProperty("user.timezone", "America/New_York");
TimeZone.setDefault(TimeZone.getTimeZone("America/Atikokan"));
System.out.println("TimeZone.getDefault(): " + TimeZone.getDefault().getID());
System.out.println("user.timezone: " + System.getProperty("user.timezone"));
System.out.println("Example java.util.Date: " + new Date());
Running this snippet on my computer gave the following output:
TimeZone.getDefault(): America/Atikokan user.timezone: America/New_York Example java.util.Date: Thu Mar 19 14:18:03 EST 2020
You notice that user.timezone prints as America/New_York, yet the last line mentions EST, so doesn’t agree with America/New_York, which would have implied EDT if I am not mistaken.
PS Usually I would discourage the use of the TimeZone class altogether since it is poorly designed and long outdated. I needed it for this demonstration since java.time, the modern Java date and time API, does not offer an option to change the time zone setting of the JVM (that I know of). Maybe they made a wise choice by not including it since — as you can see — doing that can easily cause confusion.