[tz] timezone DB distribution

[Eliot Lear]

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.

Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20200823/6cb9f11c/attachment.html>