On Sat, Apr 13, 2013 at 2:48 AM, Gwillim Law <gwillim@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 http://commons.wikimedia.org/wiki/File:2_digit_postcode_austria.png 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 Germany http://tobiasconradi.com