Date: Sat, 14 Oct 2017 23:45:20 +1100 From: "Daniel Ford" <dfnojunk@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.