paul at ganssle.io
Thu Jun 2 15:48:30 UTC 2016
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).
Using a scheme like this a date that says "2015-06-02 11:31:46 EDT+4" could be interpreted as meaning "EDT, which is UTC+4", "EDT, which is UTC-4" (POSIX), or "A time zone with no specified abbreviation that is 4 hours ahead of EDT."
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 "EDT" refers to, most software will likely default to parsing as one of the other two interpretations (which would be wrong).
That said, if "MSK-1" 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 "MSK, which is 1 hour ahead of UTC", but if you know that "MSK-1"->"MSK-9" 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.
On June 2, 2016 11:31:46 AM EDT, Random832 <random832 at fastmail.com> wrote:
>On Thu, Jun 2, 2016, at 11:02, Jonathan Lennox wrote:
>> It certainly sounds like the common usage in Russia (and in the
>> Union back in the day) is to call the timezones МСК−1 through МСК+9,
>> which would be calqued as MSK-1 through MSK+9. This is what I'd
>> recommend for Russian timezones, unless actual Russians disagree.
>The objection to this (and to using "UTC+nn" for other timezones) has
>been that someone or some code might mindlessly copy an output timezone
>abbreviation into TZ, resulting in (from MSK+2) a timezone which is
>called "MSK" and has an offset of -02:00. I don't recall if anyone's
>provided any concrete evidence of such a thing actually happening.
>[Incidentally, what should these use for daylight saving time? MSD
>itself isn't as "standard" as MSK, but is well entrenched in the Unix
>world. Or, not being constrained to three characters, use "MSK[+nn]DST"
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tz