[tz] Beginner's help request
zefram at fysh.org
Wed Nov 1 15:36:28 UTC 2017
Daniel Ford wrote:
> 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).
There are optional parts of the FTP protocol that can give timestamps, but
timestamps are relatively likely to get clobbered by accident. A better
method of checking for an update of tzdb is to look at the version number.
>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
There is not. There's an approximate correspondence for most regions,
but notably there's no "pacific" file, with most (but not all) Pacific/
zones being in the "australasia" file.
>"Why not?" :-)
Convenience of maintenance sometimes dictates exceptions, and in
those cases political affiliations have some influence, mainly through
the medium of shared DST rules. Russia spans both Europe and Asia,
each of its zones is assigned to one region or the other, but they
share DST rules, so for maintainability we have them all in one file,
arbitrarily the "europe" file. Pacific/Honolulu, for Hawaii, is in the
"northamerica" file along with the rest of the US, though since it's
never observed DST that might be more a geographical decision.
There's also an inertial effect, that we prefer not to change historical
arrangements that don't adversely affect the output. The assignment
of zones to source files is not an advertised product of the database;
it's an internal arrangement.
>I'd be very surprised (and pleased!) if I sold more than 100 clocks,
A hundred wouldn't be a worry, but by the time you've sold more it's too
late to reconfigure the ones you've already sold. You need to at least
have a mechanism for retargeting the clocks, built into all of them from
the start. You also need to think about failure modes of your control
mechanism. Learn from the mistakes that have been made in the past.
If you wanted to do hardware engineering, rather than network engineering,
you picked the wrong project.
>that becomes difficult, since I'm opposed in principle to any 'rental'
>schemes for hardware
It's not ideal, but at least, as the person selling the clocks, you have
an income that rises in proportion to the demand from the clocks. You are
the person best placed to provision a mirror with commensurate capacity.
> And the hard part, for me, would be
>setting up the server in the first place, as I have negligible experience in
Happily, you can hire people to do that bit. Isn't this "money"
It would obviously be better if there were some distribution mechanism
available that didn't depend on a single FTP or HTTP server. There's an
IETF working group looking at timezone distribution issues; you should
have a look to see whether they're addressing your use case. In addition
to the bandwidth issues, maybe they'll handle distributing binary tzfiles,
so that you don't have to parse the source.
>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,
No, even if we designed the source format anew today it would be arranged
something like this. These are *source* files, which are, and should be,
arranged for convenience of maintenance. This is why we have a separate
format, the binary tzfile, which is designed for convenience in looking
up the offset that's in effect at a specified time. Compilation isn't
just the way things are, it's a good idea.
>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?
It has been known. For about four years we had America/Argentina/San_Luis
described as year-round DST, though we've now redescribed that as a change
of base offset with no DST. It also often happens, especially where DST
transitions are selected from year to year, that it's not clear whether
a change of offset is DST or a change of base offset, so we have to guess.
Also, sometimes a southern-hemisphere DST rule says that DST ends in a
particular year and never restarts. This doesn't involve year-round DST,
just a regular decision to abandon DST. If you only look at that year's
transition and the post-transition state, you won't know about the DST
that is in effect at the beginning of the year.
Your assumption that the DST status of the zone will be the same at the
beginning and end of each year is unwarranted. DST is often cyclical,
but the exceptions are far too numerous to count on it.
>But what then? It will then need to access the TZdb to update its rules,
Yes, of course it should update. Erroring is what would happen *if it
fails to update* for years on end.
More information about the tz