[tz] timezone DB distribution

[Lester Caine]

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