Gwillim Law gwillim at gmail.com
Sat Apr 13 00:48:11 UTC 2013

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.)

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

Gwillim Law
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20130412/35422481/attachment.htm>

More information about the tz mailing list