<html><head></head><body>Just to reiterate, the objection is that I think parsing software in general will interpret something like MSK+nn and interpret it as a TZ variable timezone, or interpret it something like that, but with the sign flipped, and I did give an example of where this would come up (python-dateutil).<br>
<br>
Using a scheme like this a date that says &quot;2015-06-02 11:31:46 EDT+4&quot; could be interpreted as meaning &quot;EDT, which is UTC+4&quot;, &quot;EDT, which is UTC-4&quot; (POSIX), or &quot;A time zone with no specified abbreviation that is 4 hours ahead of EDT.&quot;<br>
<br>
Since the last one of these is not really something you can parse into a time zone unless you know that EDT+4 is a specific time zone abbreviation and what the &quot;EDT&quot; refers to, most software will likely default to parsing as one of the other two interpretations (which would be wrong).<br>
<br>
That said, if &quot;MSK-1&quot; is the name of the time zone that people actually use, the fact that it is not an essentially machine-readable format should not preclude its inclusion in tzdata. python-dateutil will naively parse this as &quot;MSK, which is 1 hour ahead of UTC&quot;, but if you know that &quot;MSK-1&quot;-&gt;&quot;MSK-9&quot; is a possibility, you can specify a mapping between those strings and the correct time zone when parsing. I imagine other date parsers have a similar strategy to resolve such ambiguities.<br><br><div class="gmail_quote">On June 2, 2016 11:31:46 AM EDT, Random832 &lt;random832@fastmail.com&gt; wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Thu, Jun 2, 2016, at 11:02, Jonathan Lennox wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> It certainly sounds like the common usage in Russia (and in the Soviet<br /> Union back in the day) is to call the timezones МСК−1 through МСК+9,<br /> which would be calqued as MSK-1 through MSK+9.  This is what I'd<br /> recommend for Russian timezones, unless actual Russians disagree.<br /></blockquote><br />The objection to this (and to using "UTC+nn" for other timezones) has<br />been that someone or some code might mindlessly copy an output timezone<br />abbreviation into TZ, resulting in (from MSK+2) a timezone which is<br />called "MSK" and has an offset of -02:00. I don't recall if anyone's<br />provided any concrete evidence of such a thing actually happening.<br /><br />[Incidentally, what should these use for daylight saving time? MSD<br />itself isn't as "stan!
 dard" as
MSK, but is well entrenched in the Unix<br />world. Or, not being constrained to three characters, use "MSK[+nn]DST"<br />or "MSKDST[+nn]"?]<br /></pre></blockquote></div></body></html>