[tz] Beginner's help request
mikeadouglass at gmail.com
Sun Oct 15 17:45:36 UTC 2017
While the tzdist protocol is http and does not (yet) handle zoneinfo
format it does seem a long way towards what you're talking about.
The main impediment (I believe) to handling zoneinfo data is coming up
with a standard format in an rfc
On 10/14/17 23:55, Robert Elz wrote:
> Date: Sat, 14 Oct 2017 23:45:20 +1100
> From: "Daniel Ford" <dfnojunk at gmail.com>
> Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAHqgwV9xKnNLs4iwQOaaXEzCgAAAEAAAAOYZ/9puZUZPkkKsORAOty0BAAAAAAemail@example.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
> 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.
More information about the tz