Replace org.joda.time with java.time and drop Joda-Time support

[wborn]

Since Java 8 (introduced in 2014) there is a java.time API inspired by Joda-Time. So it would make a lot of sense to use java.time everywhere instead of org.joda.time. Then we can drop Joda-Time support in OH3.

[kaikreuzer]

Planned to do this a long time ago already... Well, let's do it early for OH3 then 👍.

[rkoshak]

IIRC, this actually was attempted previously but java.time wasn't a drop in replacement for Joda and it broke a lot of people's Rules. OH3 would be a good time to do this as it would be a breaking change for Rules DSL at least.

[kaikreuzer]

I think you remember it correctly - thanks for the reminder!

[rkoshak]

Since this is going to break stuff anyway, is there any way we can beef up DateTimeType or somehow make it compatible with Java DateTime so we don't have to convert when we are going from a DateTime Item's state to creating a timer or comparing that state to now.

It's always seemed like it shouldn't be necessary. It's not necessary when dealing with DecimalType and BigDecimal to, for example, do math in a Rule (I'm ignoring QuantityType here of course). I just cast DecimalType to Number and I'm good to go.

Could we somehow make it so we can cast DateTimeType to Java DateTime, or add the isBefore/isAfter/plusMinutes/et. al. methods to DateTimeType and allow createTimer to accept the DateTimeType, maybe make now be a DateTimeType? That would really make it's use in Rules at least much more intuitive, even for Scripted Automation.

Just an idea and it seems this is an appropriate place to bring it up. Seems like we have an opportunity here to make a significant improvement in the usability of DateTime Items in Rules.

[wborn]

Internally DateTimeType is using a ZonedDateTime. But that type cannot be extended because it is final. So there will be a lot of boilerplate code if we want it to implement the same interfaces as ZonedDateTime:

public final class ZonedDateTime
        implements Temporal, ChronoZonedDateTime<LocalDate>, Serializable {

[rkoshak]

So instead of a cast, would be it possible to change DateTimeType to store the value as a ZonedDateTime instead of Calendar? Then instead of needing to convert it, we could just call a getter. Or maybe put a converter into DateTimeType so we can call getStateAs(ZonedDateTime) or just getZonedDateTime(). Even that would be significantly better for Rules developers.

[wborn]

The Calendar constructor is already deprecated in favor of the ZonedDateTime constructor. All the deprecated constructor does is convert the Calendar to a ZonedDateTime, see:

openhab-core/bundles/org.openhab.core/src/main/java/org/eclipse/smarthome/core/library/types/DateTimeType.java

Lines 74 to 92 in ea2ef7e

	/**
	* @deprecated The constructor uses Calendar object hence it doesn't store time zone. A new constructor is
	* available. Use {@link #DateTimeType(ZonedDateTime)} instead.
	*
	* @param calendar The Calendar object containing the time stamp.
	*/
	@Deprecated
	public DateTimeType(Calendar calendar) {
	this.zonedDateTime = ZonedDateTime.ofInstant(calendar.toInstant(), TimeZone.getDefault().toZoneId())
	.withFixedOffsetZone();
	}
	public DateTimeType() {
	this(ZonedDateTime.now());
	}
	public DateTimeType(ZonedDateTime zoned) {
	this.zonedDateTime = ZonedDateTime.from(zoned).withFixedOffsetZone();
	}

Similarly the getCalendar getter is already deprecated in favor of getZonedDateTime and all it does is convert the internal ZonedDateTime to a Calendar:

openhab-core/bundles/org.openhab.core/src/main/java/org/eclipse/smarthome/core/library/types/DateTimeType.java

Lines 134 to 144 in ea2ef7e

	/**
	* @deprecated The method is deprecated. You can use {@link #getZonedDateTime()} instead.
	*/
	@Deprecated
	public Calendar getCalendar() {
	return GregorianCalendar.from(zonedDateTime);
	}
	public ZonedDateTime getZonedDateTime() {
	return zonedDateTime;
	}

So you can save some conversion overhead by using ZonedDateTime instead of Calendars today. The ZonedDateTime also has a much better API than Calendar. :-)

I'm fine with keeping the deprecated Calendar constructor/getter because it doesn't add much and these classes are still part of the standard Java API's whereas Joda-Time is not.

[rkoshak]

My searching must have failed me. I searched and only saw the getCalendar getter.