On 23/08/2020 10:11, Eliot Lear wrote:
Hi Lester and others,
On 23.08.20 10:24, Lester Caine wrote:
Many slave devices do not rely on having a power consuming clock actually on board and instead access a master time source on the system, so the need for a full calendar system is avoided, but instead the time service needs to handle DST changes and this is where tzdist provides a documented standard to provide that area of the service.
As this discussion has demonstrated IoT is so widely varied that it is difficult to characterize a single set of requirements. There are a great many environments:
1. Consumer with an Internet connection, in which case it can use tzdist or similar, or it will have sufficient space to store the tz database, which itself was designed for efficiency. 2. BLE/BT/Zigbee device or similar with nothing. Here either it slaves time or doesn't bother at all. There are power scavenging switches that fall into this category, and certain classes of sensors like cement dryness ones that are intended to only work for 4-6 weeks on low power. 3. Full powered PLCs that do not have Internet access. These will take software updates from time to time, and will vary how much they care, depending on auditing requirements, but likely will operate in GMT for those due to synchronization issues. 4. Low powered long-lived devices. A good example of this would be a box car sensor on the railroad that has to go five years without scavenging (e.g., battery), which will periodically chirp a message. It may need synchronization with neighboring cars, but won't use a fixed time to do it because it won't have an RTC.
A great many devices will only be updated very rarely. They do not have Internet access and will be in inconvenient places, like the ground in an oil field in Alaska. Some will have downtime windows, like devices used in battle conditions. Some devices won't be put into service for years, and when they are, they'll be expected to function properly.
In all of these cases, I suspect that either TZ can accommodate them with what's there today, or there is no standard change that will accommodate them at all.
I should perhaps have elaborated a little. Certainly the devices I was coding over 30 years ago were so small that the longest time frame was 7 days on central heating controllers which were indeed GMT time only. There was no discussion on handling DST other than changing the clock twice a year. Today those elements are generally LOCALLY networked such as boiler control, thermostatic valves and even lighting control. The distributed system does not need internet access, but like most 'smart watches' these days, it can't even tell the time without it's central smart element. The key here is that these systems do not need access to the full gamete of TZ data, simply a single rule set, and even then filtered by perhaps the next couple of years. Something that tzdist serves perfectly and even flags when a forthcoming DST event may be changed from what was originally published. Saving a few bytes of space from a full TZ distribution is perhaps not the best use of time ... getting a fully functional tzdist is what is missing today? The 'distribution' mechanism, rather than the 'DB' ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk