Add quarkus.timezone to make time zone selection deterministic

[kdubb]

Description

You can read about my catalyzing issue at #43577.
Additionally, numerous similar issues have been filed over the years.

Also, when you have figured out the issue with initialization and still want to set the time zone, you need to track down where that should happen; spoiler... it's at least two or three places to make sure the time zone is set during Dev, Test, Continuous Testing**, and Prod.

It's worth noting that Continuous Testing and quarkus test were where the real problems arose; I believe this is due to forking for tests, but I'm not sure.

Currently, this simple task can produce hours of spelunking and debugging to get done. It feels like a nightmare.

Finally, our issues did arise from a bug, but it's worth noting that there's no workaround. We abandoned using @CreationTimestamp and @UpdateTimestamp altogether because we couldn't get the clock set in certain modes.

Implementation ideas

Add a quarkus.timezone property that, when set, directs Quarkus to set the Clock prior to STATIC_INIT.

This would allow developers to have a simple property to set and know that in all configurations, the time zone will be what they require, is appropriately set, and is at the right time.

Additionally, given that Quarkus has a very dynamic configuration system... setting %test.quarkus.timezone=UTC would give you a simple method to enable it only for tests and continuous testing.

[codespearhead]

If the proposed solution in #43577 works, you only need to set quarkus.hibernate-orm.jdbc.timezone appropriately for each environment.

[kdubb]

#43577 was the catalyst for this suggestion, but the idea stands alone. When you do need to guarantee a timezone, there is seemingly no way (at least no way I found) to set the timezone and have it run in all configurations (dev, test, continuous-test, prod).

Actually, I'm going to guess there is a way, but it definitely involves a lot of "figuring it out" and, from what I can tell, setting the timezone in multiple places -- a couple in build.gradle and then via the environment for running in prod.

That isn't a nice developer experience, and it should be fixed. Additionally, whatever the solution is, there's no simple documentation of it (that I've found).

[geoand]

@kdubb I completely agree that the current experience is very subpar, and I am assuming we could tackle it without too much trouble.
It would be great if you could provide some kind of sample that tests the various modes where you've encountered the problem - that way we would have a proper test to use for coming with a solution.

[chainhead]

When running as a container, I set an environment variable TZ as say, Asia/Kolkata and that seems to solve the issue.