Pedantic correction to Theory regarding size of time zone names
Line 91 of Theory: https://github.com/eggert/tz/blob/master/Theory#L91 reads:
A file name component must not exceed 14 characters …
I found one exception to this rule: The Link: Canada/East-Saskatchewan in backward. East-Saskatchewan is 17 characters. I recommend simply changing the 14 to 17. Howard
On Jul 15, 2017, at 6:02 PM, Howard Hinnant <howard.hinnant@gmail.com> wrote:
I recommend simply changing the 14 to 17.
Unless there's somebody out there 1) to whom the TZDB is important and 2) who's still using a UN*X with the old V7 file system. (1981 called, they want their UNIX file name limitations back.) But, if the only reason for the 14-character limit is to support this on file systems with the old 14-character file name limit, there's no reason to just go to 17 - we should pick an appropriate limit.
Guy Harris wrote:
1981 called, they want their UNIX file name limitations back.
tzdb's 14-character limit is like Twitter's 140-character limit: although the exact value is a relic of antique technology, the brevity is still worthwhile. Long ago Unix stored the file under the name "East-Saskatche" and this file was accessible by calling 'open' with the name "East-Saskatchewan", so the too-long file name still worked well enough for tzdb purposes. Later, some Unix maintainers caused these 'open' calls to fail on some platforms, thus breaking the name. I doubt whether tzdb users noticed or cared, as they stopped using the name years ago. The maintenance burden of the name Canada/East-Saskatchewan (evidenced partly in this thread) appears to be greater than the backward-compatibility benefit of keeping the name (as it is a misnomer and is not really used outside of test cases). So I'm inclined to comment out its line in "backward". Proposed patches attached.
On Jul 16, 2017, at 3:38 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
tzdb's 14-character limit is like Twitter's 140-character limit: although the exact value is a relic of antique technology, the brevity is still worthwhile.
(Except for those "tweetstorms" or whatever they're called; either 1) the limit is silly or 2) the limit isn't silly and the Universe is trying to tell you to use something other than Twitter for your long-form essay. But I digress....) Given TZIDss really shouldn't be thought of as names for human consumption - if your desktop environment uses them for that purpose in its time zone selection configuration GUI, go borrow somebody's Mac and see how Apple does it, and go forth and do likewise, even if it's a bit of work to dig up shape maps for tzdb zones - the 14-character limit might be OK.
On 15 July 2017 at 21:02, Howard Hinnant <howard.hinnant@gmail.com> wrote:
I recommend simply changing the 14 to 17.
No. The 14-character restriction comes from early Unix. To be a bit pedantic in return, two sentences later, the guideline refers to "Exceptions: see the discussion of legacy names below." At line 157: "Older versions of this package defined legacy names that are incompatible with the first rule of location names, but which are still supported." This includes Canada/East-Saskatchewan. Further, at line 135: "Do not change established names if they only marginally violate the above rules." In general, the rules in Theory reflect how zones should be managed moving forward, not necessarily how they always were. -- Tim Parenti
On Jul 15, 2017, at 9:24 PM, Tim Parenti <tim@timtimeonline.com> wrote:
On 15 July 2017 at 21:02, Howard Hinnant <howard.hinnant@gmail.com> wrote: I recommend simply changing the 14 to 17.
No. The 14-character restriction comes from early Unix.
To be a bit pedantic in return, two sentences later, the guideline refers to "Exceptions: see the discussion of legacy names below." At line 157: "Older versions of this package defined legacy names that are incompatible with the first rule of location names, but which are still supported." This includes Canada/East-Saskatchewan. Further, at line 135: "Do not change established names if they only marginally violate the above rules."
In general, the rules in Theory reflect how zones should be managed moving forward, not necessarily how they always were.
Ok, thanks. Howard
participants (4)
-
Guy Harris -
Howard Hinnant -
Paul Eggert -
Tim Parenti