On 02/16/2016 01:38 PM, Tim Parenti wrote:
That's not a particular obstacle; we already use SAMT for the Udmurt Republic as well
Which is equally ridiculous! People in Udmurtia surely don't think of themselves as being on Samara time. It'd be like a Missourian saying that Missouri is on Dallas time. The only reason we use SAMT for Udmurtia is because I wanted to stop inventing abbreviations and I had to put *something* in there. We should be taking these inventions out, not enshrining them.
"+0400" which is preferable to "+04"; the latter are wholly redundant with the "%z" and "%:::z" format strings offered by date
It's not redundant at all. Applications like 'date +%z' are already using portable numeric time zone abbreviations and are unaffected by our choice of abbreviations, so they are not a problem. The problem occurs with legacy or poorly-designed new applications, written by programmers who mistakenly think that the traditional "EST/CST/PST" style is generally useful. These applications are by definition not using %z or %:::z, but they still need to output *something*, and that output should not consist of our bogus inventions.
I think that's an argument for improving our toolchain accordingly, rather than shoving this into the legacy system.
What other improvements do you have in mind?
perhaps this is a transition which should be planned out more and rolled-out together across a wider set of zones once our toolchain can support it.
It would be easy to propose a patch to roll out the change to dozens of zones right away; no tool-change should be needed. My suggestion is more conservative: use the new-style abbreviations in only a few new zones at first, to give users a chance to try out the new abbreviations without changing the behavior of existing settings.