[tz] Beginner's help request
zefram at fysh.org
Tue Oct 31 19:48:43 UTC 2017
Daniel Ford wrote:
> 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
>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.
More information about the tz