Daniel Ford wrote:
User selects: First: region, from presented list. Then program displays list of cities within that region, and user picks one.
You didn't say where to get the lists of regions and cities. The list of regions is pretty fixed, but the list of cities routinely changes, mainly by adding new cities when localities that previously had identical zone behaviour (since 1970) diverge. You need to acquire the list of zones in a dynamic manner.
Then we need to download the current 'africa' file
We don't guarantee anything about the names and content of specific data source files. You can extract the list of data source files from the Makefile, by a bit of trickery: $ make check_links AWK='@echo x' | sed -n '1s/^x -f checklinks\.awk //p' africa antarctica asia australasia europe northamerica southamerica etcetera backward pacificnew systemv factory or you can use the generated source-format data file tzdata.zi, which contains everything. But parsing the source-format data files yourself is relatively hairy. You should prefer to use zic to generate the compiled data files, and extract what you need from them. The binary format of the compiled files is simpler, stabler, and provides the information you want more directly.
from the TZ FTP page
It would be a bad idea to have mass-produced consumer devices all hitting the canonical FTP or HTTP sites. You should arrange distribution to these devices yourself, at minimum by having them query a mirror that you operate.
Move forward through the file, line by line, till you find the last line of that zone entry (it's UNTIL column is empty, ... these become the current DST rules for this reference city.
No. The last line of the Zone entry provides the latest known rules for the zone, but those are not necessarily the current rules. They may be future rules that have been announced but not yet come into effect. If you want to know the rules for any specific time, including the present and near future, you *must* check the UNTIL column to find out which line of the Zone entry is applicable. 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. Even given that you're parsing the source format, this is an especially tricky way to go about it. Better to compute the whole zone's behaviour and extract the bit that you want at a later stage of processing.
If no Rule line meets these criteria, take GMTOFF to be the offset throughout the year.
No. If no Rule line is `current' by that definition, then the SAVE value of the most recent pre-`current' rule applies. Indeed, even if there are `current' Rule lines, if the time of the first one has not yet arrived then the SAVE value comes from an older rule, not from any of the `current' ones. It is not correct to divide rules into `current' and non-`current' in the way that you describe. The way to understand Rule lines is that they describe a series of transitions and (part of) the state of the zone between those transitions. There is no artificial distinction between one year's state and transitions and another year's; there's just a sequence of transitions, which can occur at any time. Where a Rule line specifies a range of years, then that's a formula for constructing multiple transitions. Transitions are instantaneous events, and so are never meaningfully "current". The only thing that's current is the state of the zone, which is whichever state applies between the most recent transition in the past and the nearest transition in the future. That state will be specified by the Rule line that defines that most recent past transition. For your clock, you're probably best off not attempting to have the clock store rules that can be applied indefinitely far in the future. Better to compute a few years of explicit future transitions, and have the clock just work its way through the list, eventually erroring if it's gone years without updating its knowledge. -zefram