date/time property

[mjcumming]

Wondering if any thought has been given to a way to represent date/time and to set date/time.

Use case is for setting the hold mode on a thermostat where the hold mode can be permanent or temporary. When temporary, a time is supplied for when the hold mode expires.

[davidgraeff]

Not yet. We should pick a simple to parse RFC date/time representation

[Thalhammer]

Should probably stick with a common one: https://en.wikipedia.org/wiki/ISO_8601

[mjcumming]

looks good to me - there is python support for it :)

[krocans]

Isn't unixtime enough for that? To include some human readable time/time zone representation in specification means to force to implement additional code in every Homie implementation even on small devices where code/data size matters.

[stritti]

To implement timebased rules I also looking forward datetime support. Currently I split hh and mm in separate float properties.

[davidgraeff]

Another possibility is NTP

Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h. If only 32bit integers are used in both cases we run into trouble at some point.

[stritti]

I would prefer ISO. Then it is much easier to define for example time ranges too. For example to define when a switch is daily enabled/disabled.

[mjcumming]

ISO seems to be a more common standard. I am not sure that controller devices have to implement a datetime format? If they do not send that data, then do they need to be able to process it? How much overhead would this be? There are libraries in C, C++ and Python.

[davidgraeff]

I think ISO is fine. So we would allow the following patterns:

2019-04-17T23:59:33+00:00
2019-04-17T23:59:33Z

[mjcumming]

@davidgraeff are you suggesting we implement a subset of the ISO standard or implement the full standard as documented?

https://en.wikipedia.org/wiki/ISO_8601

[davidgraeff]

A subset. I don't want to support:

The standard also allows for calendar dates to be written with reduced accuracy. For example, one may write "1981-04" to mean "1981 April".

or

One may simply write "1981" to refer to that year or "19" to refer to the century from 1900 to 1999 inclusive.

or

Although the standard allows both the YYYY-MM-DD and YYYYMMDD formats for complete calendar date representations

[stritti]

But I think it should be possible to define a specific datetime-stamp and on the other hand returning times or durations which means just time without date.

[davidgraeff]

I meant my two lines above as example not as the final decision. Yes I agree, it should be possible to just specify date or time.

The Iso also covers a variety of short patterns and time zones. A subset should be sufficient for the Homie domain?!

[stritti]

First I thought timezone could be dropped, but what about communicating with some external clouds and daylight saving times 🙄 It will in this case be difficult to support just +1 or similar. But on the other hand, shall we really implement in every ESP timezone support?

What are your use cases/ user stories?

My user stories are:

• the end user would like to set current time and timezone to show the local time on the device.
• the end user would like to set hh:mm to enable/disable switch everyday on this time.
• the end user would like to set weekday and hh:mm to run XX every week.
• the developer would like to send timestamp of the device to check its heart beats.

[Thalhammer]

I think we should stick with UTC only, as it reduces the work needed on devices by a lot. Simple yyyy-mm-dd hh:mm to time_t can be done without much effort, in small code sizes and without looping (i.e. its cheap) while supporting Timezones would require A LOT of additional information either as a binary file or as generated code (neither of which I'd like to have, if I don't need to). A controller usually runs more powerful hardware anyway, so I guess its ok to assume it will have enough resources while a device might only have UTC times.

I don't see any reason where you would actually need anything else than utc except for convenience (the controller can just convert to utc and back as needed), but I might be wrong.

[davidgraeff]

UTC is fine. I would include the separating "T" like in the ISO. That format can be parsed by many programming languages directly.

[stritti]

Yes that is a good argument: timezone could be managed by controller.

[mjcumming]

Any device using time will need a way to get/set the current time. I would assume that most devices like the ESP (which do not have a RTC) will need to get that time using an NTP server. I don't imagine adding the ability to parse a time string be it ISO or other format will have significant overhead compared to the libraries already required to talk to an NTP service.

[lorenwest]

Agreed it would be valuable for the spec to define time strings consistently.

2019-04-17T23:59:33+00:00
2019-04-17T23:59:33Z

In my opinion, it's important for dates to have optional time, including optional milli/micro seconds. Sometimes it matters...

2016-06-10T21:42:24.76073899Z

FWIW, I synchronize time to my Homie devices from the controller using $broadcast. That's a lot simpler than NTP from each device, and may be a good addition to the convention. The time format would be (of course) whatever we decide in this thread :)

[mjcumming]

I would like to clarify some verbiage - in the Homie convention, there is no real concept of a "controller". Ie. there is no one device or instance that is in charge of other devices on the network - correct?

I understand that most will use the convention with something like OH being considered the controller or master device but that is not defined in the scope of the convention.

So, I am not sure that the idea that one device will define the time in that location for all other devices on that network fits within the convention. However, if devices are going to communicate date/time information we do need to describe the expectation that devices on that network know the local time.

[davidgraeff]

there is no real concept of a "controller".

Wrong. See https://homieiot.github.io/implementations/. We have controllers vs devices.

one device will define the time

That was not suggested?! And it will definitely not be part of the spec. And is offtopic ;)

[mjcumming]

My mistake regarding controllers. In terms of time, it was suggested by @lorenwest that one device/controller could define the current time by a $broadcast.

[wwebers]

I agree with @Thalhammer : UTC would be fine. Question is, will we support durations and intervals?

[davidgraeff]

This issue is purely about date and time. Duration/intervals would be a different Issue and a different ISO, DIN or other specification need to be used.

[Thalhammer]

@mjcumming Yes thats the way most implement clock distribution on the network but it is not specified anywhere in homie. Also I dont think it should be as there are a lot of ways to sync clocks (like ntp, which I use).

@wwebers We will support durations and intervals, but not in this issue.

[mjcumming]

DateTime payload added to the convention using ISO8601