Date: Fri, 06 Apr 2001 13:08:42 +1000 From: Greg Black <gjb@gbch.net> Message-ID: <nospam-986526522.67277@maxim.gbch.net> | I can't force people who write to me (who are often people I | don't know) to replace their mail software just because I don't | like the dates it generates. No you can't - nor can you force people to set their clocks correctly so you can sort mail by date either. Basically "sort by date" is always going to get things wrong, for one reason or other, if you want to perform that kind of sort, you're just going to have to live with that. | However, if the TZ data gave the | Australian users unambiguous abbreviations for those zones, it | would make life easier at little or no cost to anyone. No it wouldn't. You can no more force those people sending from one of the very few mailers that still has that broken behaviour to update their timezone names than you can get them to update their mailers. If you believe that you can get something fixed, it would be far better for everyone to have the mailers they use fixed so they generate Date headers that conform to the RFCs, than to try to have them "fixed" via the back door (by changing the timezone string that the mailer gets handed) so that they now violate the RFCs (EST is legal in the Date header, AEST is not). The right way to achieve that is to bug the people who maintain the mailer in question of course - not those who are merely its users. If the people in question (those sending you this broken mail) won't install an updated version of the mailer they use, then it is unlikely anything that is done is going to fix the problem for you - at the very least you'd need to wait until there is yet another change to the AU timezone rules, which might encourage some people to install updated tzdata files. | I don't agree, unless the cost is significant. As far as I can | see, the cost here is nil. For nil cost you get nil effect. Something has to change, and someone has to make that change - that has costs. | | On the other hand, there is another motivation for unambiguous | | abbreviations: it cuts down on human confusion. This is | | particularly true for Australia, where "EST" can mean one thing for | | time T and a different thing for time T plus 1 second. | | This is an important point. Perhaps - whether having the abbreviation the same is better, or distinct is better, depends entirely upon the application for which it is to be used. If you're attempting to parse it, and decide what offset from UTC it means, then distinct would be better (that's what sorting broken Date headers requires). But that isn't a sane thing to be doing with timezone abbreviations in any case. For simply specifying a time having them the same works much better, as you never get odd things like "Sat Apr 7 13:59:33 AEDT 2001" which would be a date/time/zone combination that simply doesn't exist. When it is written as "Sat Apr 7 13:59:33 EST 2001" you don't even think about the timezone, other than to see "that's the one that applies where I am" so you simply see ("about 2pm Saturday wall clock time). Its the convenience of the latter that makes me think that the choice of "Summer Time" to go with "Standard Time" was very deliberate, so the abbreviation would remain the same. kre