DPTXlatorDateTime: DST handling problem about calimero-core HOT 4 CLOSED

The calendar object sets or resets the dst offset according to the given date, Are you sure you didn't have a default timezone that does not have a DST or used a historic date that didn't have DST yet.

from calimero-core.

Yes, you're right. My testcase was wrong. Wrote it without thinking about different timezones.

But, the translator's setData() method accepts 1900/01/01 00:00:00 DST (0x00 01 01 20 00 00 01 00) without throwing and so does getValue() returning "1900/1/1, Mon (no workday) 0:0:0 DST, no sync". This fails only when using getValueMilliseconds() where an exception is thrown.
Btw: same behavior when setting 2014-07-31 00:00:00 (without DST flag being set).
Question I have is: when is the byte data validated? I might (wrongly) assume that setData() should do that.

from calimero-core.

Actually, this is described in the API doc. The reasons for that behavior are, that

1. the KNX DPT specification does not require any valid date/times (besides valid ranges per field).
2. a valid date/time item does not require to have filled in all fields
3. calendars can differ.

Therefore, unconditional calendar validation might fail unexpectedly, although the datapoint value is valid. You could never translate data that does not pass your calendar. Those two are different requirements on the data (valid calendar time being stronger).
getValueMilliseconds returns the UTC milliseconds based on your calendar's epoch (to be useful), calendar validation is important.

Answer: If you want the date/times to be validated against your calendar, call validate.

from calimero-core.

Thx for letting me know.

from calimero-core.