Unify the timezone management for logs across Zowe server

[balhar-jakub]

Is your feature request related to a problem? Please describe.
There are two ways to handle logs and their timezone on the server.

1. Use UTC timezone regardless of where the servers are located
2. Use the local timezone of the server

Describe the solution you'd like
I want one configuration option shared across the zowe server in zowe.yaml which decides what timezone is used:

• Local
• UTC
• UTC moved by certain time.

It's possible that this is already supported within logback and the change for API ML will happen only in the logback.xml

Describe alternatives you've considered
The current situation for API ML is that the logs are always in the UTC timezone

[1000TurquoisePogs]

From prior notes:

I think the area associated with timezones is here:

api-layer/apiml-common/src/main/resources/logback.xml

Line 8 in 7334a82

<property name="apimlLogPattern" value="%d{yyyy-MM-dd HH:mm:ss.SSS,UTC} %clr&lt;${logbackService:-${logbackServiceName}}:%thread:${PID:- }&gt; %magenta(%X{userid:-}) %cyan(%-5level) %clr\(\(%logger{15}\)\) %msg%n"/>

And I suggest that zowe as a whole respect a YAML property on whether to use UTC or Local time. The third option of "UTC moved by a certain time" could also be valid but maybe overkill?

Here's the YAML property I proposed in a draft to zlux code which did the trick fine: zowe/zlux-server-framework#572

[balhar-jakub]

Thanks for sharing Sean. Yes this is the area associated with what timezone the logs will occur in.

I fully agree that there needs to be property within zowe.yaml that will be respected by all zowe components on the server side.

Given that this is currently configurable, there is a workaround to change this line, if someone desperately needsthis resolved, but what we as API ML squad need to experiment with is how exactly this line needs to look like for UTC and local timezone. Also how do we change this line programatically. With our current knowledge we may need to provide multiple logback.xml files and then switch them based on the yaml property. I don't think this is a good solution.

As for the third option, I added it for completeness. I believe that it's lowest priority and I agree we definitely won't work on it until the first two are solved and most probably even afterwards. I actually expect it to be removed as we refine the issue, but thanks for sharing your opinion on it.