Not Planned

0

Is it possible to change the pod zone timings in XL-Release backend

by: ALM t. | 5 days ago | *All other
Cast your vote or comment ...
return to idea list

Hi Team,

Issue: we have seen the UTC time zone in our XL-Release application and back end configuration logs

To resolve the above issue, we have applied the extra spec variable(adding CET time zone) in CR file, after pods restart, we can able to see the CET time in logs and application level (system information)

However, the pod zone timings are showing as default UTC time, we want to change the pod zone timings to CET only, and whenever we connected with DAI support team below is the response

"proposed dai-release_cr.yaml config changes will take affect for XLRelease application running inside the pod and this was confirmed when release pod logs and System Information in XLRelease UI showed the updated time in respective CET timezone. Pod timezones are irrelevant / out of scope for Release Operator with proposed config change will only control the XLRelease application. Maybe you can file a feature request on this regard in our Devops Ideaspace for our Product Management Team to check further."

So just checking is it possible to enable the pod zone timings in XL-Release, so just adding the screenshots for your reference


Thanks
Raveendra

by: ALM t. | 5 days ago | *All other

Comments

  • Hi Team,

    kindly provide your valuable solution/suggestions/ideas on this topic, it would be really helpful to us

    Thanks
    Raveendra

    by: ALM t. | 4 days ago

  • By default, the Release pods run in UTC, which aligns with how Kubernetes and most containerized environments are designed - for consistency across distributed systems.

    Within the application itself, Release already supports converting timestamps to the desired timezone (e.g., CET), both in the UI and in the logs, using the configuration provided in the CR file. This ensures that relevant application-level time information reflects the expected local time without requiring changes to the pod's system clock.

    Changing the underlying pod timezone is not something Release configures today, as it can introduce inconsistencies and make debugging or automation workflows more error-prone - especially in environments where multiple pods or services interact.

    by: DevOps Product team | about a day ago
    official response

  • Hi Team,

    Thanks for the clarification and this can be closed

    Regards
    Raveendra

    by: ALM t. | about a day ago