On Thu, 4 Dec 2003, Anton Berezin wrote: > Maybe have a default aliases like "certain annoying OS's", to borrow > your expression? As a matter of fact, last time I tried, Linux did the > same thing - understood them. "EST" actually designates Indianapolis > time - America/Indianapolis and EST are hardlinked (I presume because it > is "EST" all year round), and "CET" is, I believe, quite unambiguous.
Well, if the OS symlinks /etc/localtime to /usr/share/zoneinfo/EST, which is in turn linked to /usr/share/zoneinfo/America/Indianapolis, that's fine, so we eventually arrive at something usable. > Even funnier still, the zoneinfo package is exactly the same on Linux > and FreeBSD, or at least on Debian and FreeBSD, and there is a whole > bunch of three-letter abbreviations there. So why to struggle against > the OS? For an abstract correctness, which might not be that correct Because the OS is wrong in this case. > Since you did not buy the "tools not policy" principle, I appeal to the > "principle of least astonishment", which in this particular instance > means to support what people expect and what OS's implement. You may > "strongly urge against using three letter abbreviations" because they > are not correct, but not supporting them outright would, IMHO, be a > mistake. I disagree. Not supporting them outright is almost certainly abiding by the "principle of least astonishment", since someone from Australia may well be quite astonished if they ask for EST and get America/Indianapolis. Now, if someone wants to add some code to DateTime::TimeZone::Local that, given an abbreviation, looks at the zoneinfo files and figures out that EST is a copy (as on my Debian box) of America/Indianapolis, and therefore turns EST into America/Indianapolis, that's fine with me. But since I cannot be sure that on other systems EST doesn't mean something else, I'm not going to hard code this into the package itself. -dave /*======================= House Absolute Consulting www.houseabsolute.com =======================*/
