Zefram, "You didn't say where to get the lists of regions and cities." I had planned to hard-code these from zone1970.tab into the clock, but since you've mentioned that they sometimes change too, I'll now have to download that file (whenever it changes) to the clock too. I've never coded FTP into an embedded system before, but I'm hoping there will be some way the FTP routines (in the Arduino FTP library I've downloaded) can determine (without downloading) whether a file has changed since 'the last time' (e.g. by date-stamp). "We don't guarantee anything about the names and content of specific data source files." I had naively assumed that there was a 1:1 correspondence between region names in zone1970.tab and file names containing zones/rules for those regions. Is this not correct? If not, I would have to (impertinently) ask: "Why not?" :-) I think I mentioned in one of my early mails that I am a PC/Windoze user, so unfortunately all the code tools you provide for the TZdb are of little use to me. That's why I'm trying to tackle the *source* (ASCII) data directly, rather than any binary files. It might be hard, but if all the required information resides in those text files, it must be possible to tease it out, somehow. That was my aim with my suggested 'algorithm'. "It would be a bad idea to have mass-produced consumer devices all hitting the canonical FTP or HTTP sites." OK, I'm getting the impression that the TZdb site is bandwidth-limited. But I'd be very surprised (and pleased!) if I sold more than 100 clocks, and surely the TZdb site would handle 100 FTP requests spread randomly over a week? In the event that my clock became a runaway success and sold many more, I would then look at setting up a site to serve data to them. But that becomes difficult, since I'm opposed in principle to any 'rental' schemes for hardware (and software for that matter, though I reluctantly live with that reality), so would have to pay for the running of that website from one-off profits - not a good recipe in the long-term. Anyway, I think that's an unlikely scenario. "...you *must* check the UNTIL column to find out which line of the Zone entry is applicable." Understood - thanks for the pointer. So that part of my algorithm should change to say: ----- Move forward through the file, line by line, till you find a line of that zone entry whose UNTIL column contains a post-current date, or (if none with such a value) is empty. ----- "But more generally, parsing within a source-format data file to find the specific part of a zone's data that you want sounds like a bad idea." I agree - it's a horrendous job, made difficult by the particular way the database data is presented, with no file just containing 'current' rules in a simple format. This is obviously an historic inheritance, and the database has presumably grown 'like topsy' to be the way it is today. Of course the clever people who maintain it have come up with complex code to process and extract the data in a simpler form, but that is not available to me. I had (perhaps forlornly) hoped that someone could set up some code (run whenever the database contents changed) to do that extraction and create a single 'current' file that lists all zones and DST rules *at the current time*, and include that results file in the database for access by non-Unix folk like me. But if that can't happen, I'm stuck with parsing within source-format data files. "If no Rule line is `current' by that definition, then the SAVE value of the most recent pre-`current' rule applies." Let me see if I understand this... Are you saying that some jurisdictions will make a *permanent* change to DST (+1hr from 'standard' time, for example) *rather than* officially changing their GMT-offset? "Transitions are instantaneous events, and so are never meaningfully 'current'." I understand that. What I mean by a 'current' rule is: "this rule applies to the DST transitions for this year." For me, a 'current' rule does not define the current time; it defines the expected near-future *changes* in GMT-offset (to/from DST). This is all I need - the 'current' DST rules. The clock's firmware then monitors those rules and makes the offset changes when the corresponding UTC occurs, as you saw in the video I linked earlier. "Better to compute a few years ..., eventually erroring if it's gone years without updating its knowledge." But what then? It will then need to access the TZdb to update its rules, so we're back to where I started - the need to check occasionally for updated rules. I agree that in most 'stable' jurisdictions there will be no changes for years, and in this case the clock would just check if the rules for its installation locale have changed (by date-stamp?), and only download the new files if they have. But to allow for clocks being bought and installed in 'unstable' (time-rule) jurisdictions, I would want the clock to check for updates every week or so. Paul, "Then I'm afraid you'll need to change your setup. Sorry, but IANA has limited resources and it cannot be the direct central server for all the clocks on the planet. It should be easy for you or your successors to maintain a server for your customers' clocks, a server that is a clone of the IANA server." Understood. As mentioned, this is not a 'commercial' project in the normal sense. It's a hobby project (for my own use) that I hope might make a little pocket money from eBay sales too. It's unlikely my children would be interested in maintaining my server. And the hard part, for me, would be setting up the server in the first place, as I have negligible experience in that department. I'll give my approach more thought after I've mastered the interpretation of the TZdb and how to extract the desired info from it. Regards, Daniel