<div dir="ltr"><div><div>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.)<br>
<br></div>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.<br>
<br></div>Gwillim Law<br><br></div>