User timezone caching

[KeithRaven]

Fix for issue #15536

[github-actions]

This pull request has merge conflicts. Please resolve those before requesting a review.

[hishamco]

Fix the merge conflict

[KeithRaven]

Switched to draft as there's still a point for discussion in the linked issue.

[github-actions]

It seems that this pull request didn't really move for quite a while. Is this something you'd like to revisit any time soon or should we close? Please comment if you'd like to pick it up.

[hishamco]

@KeithRaven is this something you will revise soon?

[github-actions]

This pull request has merge conflicts. Please resolve those before requesting a review.

[MikeAlhayek]

for instructions on how to resolve the merge conflicts due to #16572 please follow the step listed in this comment.

[github-actions]

It seems that this pull request didn't really move for quite a while. Is this something you'd like to revisit any time soon or should we close? Please comment if you'd like to pick it up.

[github-actions]

Closing this pull request because it has been stale for very long. If you think this is still relevant, feel free to reopen it.

[hishamco]

@deanmarcussen can we reopen this and accept this PR?

[KeithRaven]

Apologies for letting this slide. If I can get an opinion on the question I asked in the issue re appropriate absolute expiration time #15536 (comment) then I'll get this tidied up and re-tested

@deanmarcussen had suggested having an absolute expiration as a backstop as well to mitigate some potential issues with distributed caches. Just wasn't sure what time was appropriate.

[deanmarcussen]

conceptually fine, but code has since been refactored by someone else and the cache inside the UserTimeZoneService is now essentially useless, so the new issue is what really needs fixing (at which point this could be visited as the idea is good, but where it is, is no longer useful.)

refer : #16392