Tobias Conradi mail.2012 at tobiasconradi.com
Wed Apr 17 18:09:31 UTC 2013

On Sat, Apr 13, 2013 at 2:48 AM, Gwillim Law <gwillim at gmail.com> wrote:
> When I was a data administrator, one of the most fundamental principles I
> learned was not to try to embed one field as a code inside another one. For
> example, most Austrian postal codes allow you to infer the state from the
> first digit. The postal code 5016 is in Salzburg; Koppl is 5321; Tenneck is
> 5451; they're all in Land Salzburg. So why not use the postal code field to
> figure out which state a place is in? Because sooner or later, someone will
> change the system. (In fact, there are already a few exceptions in the case
> of Austria.)
If you look at
you can see the codes are organized, the first digit gives a larger
region, the first two a smaller one.

The postal code designers did exactly what you "learned" not to do.

> I believe that the same principle applies to tz abbreviations. If
> programmers get the idea that they can rely on the next-to-last letter of
> the tz abbreviation to represent the offset from standard time, with H = .5
> and D = 1, at least a few of them will start writing code that makes that
> assumption. (Some programmers love to think up tricks like that, in order to
> save a line or two of code.) It's just not a good data design. The tz
> database contains a field that's defined as the offset from standard time,
> and it's expressed as a time, not a letter code. Force the programmers to
> use that field. Never suggest that the next-to-last letter can be used
> instead.
One of the reasons for not using D in %s for anything else than 1:00
saving is, to reduce the chance for ambiguity if 0:30 saving and 1:00
exist in one region at the same time, or at different times in the
same year.

The Austrian postal codes designer fixed one digit for one area (e.g.
6), so that with the next digit they did not have to care about
collisions within another region (e.g. 7).

Systematization and globally time point unique abbreviations have
benefits, that are not reduced by programmers do their personal
programming. It can happen all the time that a programmer codes
against unspecified behavior. That doesn't mean specified behavior has
to stop.

Tobias Conradi
Rheinsberger Str. 18
10115 Berlin


More information about the tz mailing list