Skip to content

Conversation

mawinter69
Copy link
Contributor

@mawinter69 mawinter69 commented Sep 13, 2025

This avoids that the timezone needs to be parsed frequently. This change is compatible from api and persistence perspective so no extra conversion is required.
A change in core should be opened to allow the 2 classes generally that are now added explicitly.

Alternative to #425

Testing done

Before this change configured the timezone to Etc/GMT-9, then started with this change and timezone is properly set to Etc/GMT-9 in the UI and when scheduling a build. Also tested with other timezones in a similar way.

Submitter checklist

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests that demonstrate the feature works or the issue is fixed

This avoids that the timezone needs to be parsed frequently.
This change is compatible from api and persistence perspective so no
extra conversion is required.
A change in core should be opened to allow the 2 classes generally
that are now added explicitly.
@mawinter69 mawinter69 requested a review from a team as a code owner September 13, 2025 18:13
@@ -0,0 +1,2 @@
java.time.ZoneRegion
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Both classes are needed. The first during saving and the second when loading

@jglick
Copy link
Member

jglick commented Sep 24, 2025

Prefer something like #425.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants