Fix TlvEncoder Date encoding for dates in a distant future (exceeding MAX_INT)

[jakubsobolewskisag]

If encoded date is in distant future (number of seconds since 1970 exceeds MAX_INT), TlvEncoder breaks because it always tries to encode dates as 4-byte integers. This fix checks whether number of seconds exceeds MAX_INT, and if it does the value is encoded in 8-bytes. Otherwise, previous behavior will be used (4-bytes).

[sbernard31]

Thx for the contribution 🙏

Looking at LWM2M-v1.1.1@core§Table: C.-2 Data Type Mapping
about Time for TLV :

Same representation as Integer.

Does it means that Date encoding should look more like :

leshan/leshan-lwm2m-core/src/main/java/org/eclipse/leshan/core/tlv/TlvEncoder.java

Lines 64 to 81 in f9137bb

	public static byte[] encodeInteger(Number number) {
	ByteBuffer iBuf;
	long lValue = number.longValue();
	if (lValue >= Byte.MIN_VALUE && lValue <= Byte.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(1);
	iBuf.put((byte) lValue);
	} else if (lValue >= Short.MIN_VALUE && lValue <= Short.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(2);
	iBuf.putShort((short) lValue);
	} else if (lValue >= Integer.MIN_VALUE && lValue <= Integer.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(4);
	iBuf.putInt((int) lValue);
	} else {
	iBuf = ByteBuffer.allocate(8);
	iBuf.putLong(lValue);
	}
	return iBuf.array();
	}

?

[jakubsobolewskisag]

Thx for the contribution 🙏

Looking at LWM2M-v1.1.1@core§Table: C.-2 Data Type Mapping about Time for TLV :

Same representation as Integer.

Does it means that Date encoding should look more like :

leshan/leshan-lwm2m-core/src/main/java/org/eclipse/leshan/core/tlv/TlvEncoder.java

Lines 64 to 81 in f9137bb

	public static byte[] encodeInteger(Number number) {
	ByteBuffer iBuf;
	long lValue = number.longValue();
	if (lValue >= Byte.MIN_VALUE && lValue <= Byte.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(1);
	iBuf.put((byte) lValue);
	} else if (lValue >= Short.MIN_VALUE && lValue <= Short.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(2);
	iBuf.putShort((short) lValue);
	} else if (lValue >= Integer.MIN_VALUE && lValue <= Integer.MAX_VALUE) {
	iBuf = ByteBuffer.allocate(4);
	iBuf.putInt((int) lValue);
	} else {
	iBuf = ByteBuffer.allocate(8);
	iBuf.putLong(lValue);
	}
	return iBuf.array();
	}

?

@sbernard31 Hmmm... I guess you're right. We can encode integers in 1, 2, 4 or 8 bytes. That would be the most optimal. I will change the code and add unit tests.

[jakubsobolewskisag]

@sbernard31 done - I think I covered all of the edge cases in the unit tests.

[sbernard31]

This is now integrated in master (squashed in 1 commit 2a1a8af), it should be soon available leshan sandbox and will be part of 2.0.0-M16 (#1629)

Thx @jakubsobolewskisag 🙏