[tz] Beginner's help request
dfnojunk at gmail.com
Wed Nov 1 11:51:06 UTC 2017
"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
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
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
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
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.
"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
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.
More information about the tz