I have OpenHab 2 working with MQTT and a growing MySensors network. For a couple of my the sensors, it would be good if I could synchronize the time. MySensors has a method to request the time from the controller. The value passed back to the sensor should be a Unix timestamp. I think I can figure out the rule to respond to a given MQTT request from the sensor and send out the response, but I can’t figure out how to calculate the value for the response.
I can get the UTC Unix Epoch with:
var n = now
var e = n.getMillis
but then adjusting this for my timezone and adjusting for DST is where I am stuck.
If full java classes are allowed you could use Calendar.getInstance().getTimeInMillis(). The calendar class is quite sophisticated and considers timezones etc and allows manual adjustment with addHour().
Typically when one is working with timestamps in milliseconds one is working with epoch. This is the number of milliseconds since midnight January 1st, 1970 GMT.
You do not calculate timezone and DST. Epoch is fixed. It is the tools that show you the date/time in a nice friendly human readable form that calculates all of that based on the epoch.
Put another way, to synchronize your times just use now.getMillis. There is nothing to calculate.
Thanks for the responses - the MySensors API expects that the controller will delver the number of seconds from January 1 1970 corrected for the local timezone.
Is there a way I can determine the difference between UTC and the current timezone so I can provide the expected value to a MySensors query.
I don’t think this makes sense. The number of seconds since January 1 1970 is an absolute measure that will not change with the timezone. The representation as local time, however, will change, but as I understand it that is not what you are after?
