[tz] Beginner's help request

[Robert Elz]

    Date:        Sat, 14 Oct 2017 23:45:20 +1100
    From:        "Daniel Ford" <dfnojunk at gmail.com>
    Message-ID:  <!&!AAAAAAAAAAAYAAAAAAAAAHqgwV9xKnNLs4iwQOaaXEzCgAAAEAAAAOYZ/9puZUZPkkKsORAOty0BAAAAAA==@gmail.com>

The issue of how to get the current offset, and the next planned alteration
(if any) (and perhaps one or two more after that) is, or has been, dealt
with by others already - though I might add, that the tzdata files that
you looked at are really only intended to be processed by zic, though there
are a couple of other tools around that also do it.

The output from zic however is a binary file that contains almost exactly
what you want - the suggestion to use zdump is basically just converting
some of that binary data into text form, but really, for what you want,
if you get text, you're just going to have to translate it back to binary
again anyway, so you might as well just parse the zoneinfo binary files,
and get the data from them (that's what the unix libc functions do when
some application wants to convert a "seconds since..." timestamp into a
clock (time of day, plus date) type time.

There is (at least one) windows port of the tzcode I believe, so doing it
this way, even if you have to suffer doing it on windows, is not impossible.

But ...

  | Given that DST 'rules' can change at the whim of governments, my firmware
  | will need to annually look up 'current' DST rules from the web.

This is actually the hard part.  Annually is not nearly often enough,
the rules can change with just weeks (or sometimes) days, of advance
notice.   If your clocks are using old data, they'll end up showing
the wrong time if they are in an affected area.

Either you need to have them poll daily (at worst) which could be a
huge load on whatever server you have them contact (if your clock becomes
successful, of course) or you will need to find some other way to notify
the clocks when they ought to be fetching updates.   If you are polling
you could lessen the load a bit by not using HTTP (or anything related to
"the web") and instead using a simpler protocol, which could start with a
simple UDP type "has anything changed for zone xxxx since time X" which
would send a simple "last change for zone xxxx was @Y" or something reply
(one small simple packet each way.)

Then only when there has been a change would you use a more robust
protocol to actually fetch the updated data (that could be http based,
if that is essential).

If a new protocol for the UDP part sounds too risky, you could even (ab)use
the DNS - have the clock send a DNS query for a TXT record for
zone-name.some-domain.net (were some-domain.net is something registered
just for the purpose).  The returned TXT record would contain the data that
you need.  That way you get the benefits of DNS caching.

The point is that this part needs careful consideration and design, as
whatever you start with will be very hard to ever change once you have
devices out in the wild, and that you really do need to verify the data
frequently to have any confidence in it at all -- and someone needs to make
sure the server is being updated - monitoring this list probably, as it
happens sometimes that zones are updated with so little notice that
the tzdata distributions cannot keep up, and only include the updated
data sometime after the change has become effective - usually this list
will hear about it very quickly, which would allow someone monitoring
what appears here to update the server even before there's new tzdata
available.

kre

ps: I would suggest including a GPS receiver in the clock - as they are
in every phone these days, they have become cheap enough for this I think.
That way your clock can display accurate time with much less network
overhead than it would using NTP (and typically with much less code.)
The network time option would still be useful for clocks located in
environments where satellite reception is not possible though.