Resurrect timezone

[Nadahar]

This is my suggestion to remedy what I described in #5354.

It does not revert the bulk of #3583, it only reverts the erasure of the timezone from DateTimeType, plus deprecations and other "reductions in functionality" that resulted from it.

At the same time, I've tried to address the problem that was the motivation being #3583 as far as I've been able to figure out: The fact that binding authors had to apply the correct timezone when creating timestamps (aka now()).

The way I've addressed that, is that I've introduced a "new concept" in DateTimeType, "authoritative timezone". If the timezone is authoritative, it means that it correctly represents the source moment in time. If it's non-authoritative, it means that it's a "valid timezone", but might not be the desired one. When DateTimeTypes are posted to the event bus, any instances with a non-authoritative timezone will get the OH configured timezone applied, and made authoritative. That way, binding authors don't have to acquire the correct timezone when generating timestamps, but they can specify a timezone that will be preserved if the source is something else, like something read from a device or online API. The same "benefit" also applies to scripts, they can also just use DateTimeType.now() to get an instance with a non-authoritative timezone, that will automatically be converted to the OH configured timezone before entering the even bus.

As far as I can tell, this should give "equal relief" to binding authors as the current solution, while avoiding all the negative side effects that exist today.

In addition to "resurrecting timezone handling", I've added a number of "convenience methods" to DateTimeType that should make them easier to use directly, requiring less conversion to other types before manipulation. There typically mirror the ones found on the standard Java Temporal types:

• truncatedTo(TemporalUnit unit)
• until(Temporal endExclusive, TemporalUnit unit)
• until(DateTimeType endExclusive, TemporalUnit unit)
• plus(TemporalAmount amountToAdd)
• plus(long amountToAdd, TemporalUnit unit)
• minus(TemporalAmount amountToSubtract)
• minus(long amountToSubtract, TemporalUnit unit)
• isAfter(DateTimeType moment)
• isAfter(ChronoZonedDateTime<?> moment)
• isAfter(Instant instant)
• isBefore(DateTimeType moment)
• isBefore(ChronoZonedDateTime<?> moment)
• isBefore(Instant instant)

DateTimeType is still immutable, so the methods that return DateTimeTypes, return new instances.

Fixes #5354.

[Nadahar]

@jlaur FYI

[Nadahar]

Fantastic. The Java25 build fails because they have decided to deprecate 3 letter timezone designations:

java.lang.IllegalArgumentException: 2012-04-08T18:23:12FJT is not in a valid format

This is perfectly valid in Java21, and I've used both in tests. Isn't it great how they just love to make life difficult for people by deprecating things that have worked for years. I know that the 3-letter codes has issues, that there are collisions, and that Java used to resolve the ambiguity by looking at the configured locale. It's not "ideal", but it has worked for years and years, and most codes don't collide with anything.

It's if some people think that there are too few problems in the world, so they do their best to invent some. I guess I will have to "clean" the tests for 3-letter timezone codes then.