Re: [tz] Astrakhan region got approval to change its time zone
I'm more concerned with end-user confusion on whether +04 means GMT+04 or MSK+04. ________________________________ From: Paul Eggert<mailto:eggert@cs.ucla.edu> Sent: 2/13/2016 6:03 PM To: Brian.Inglis@systematicsw.ab.ca<mailto:Brian.Inglis@systematicsw.ab.ca>; tz@iana.org<mailto:tz@iana.org> Subject: Re: [tz] Astrakhan region got approval to change its time zone Brian Inglis wrote:
I just know a bunch of people out there are cluelessly checking this string is upper case alpha.
We crossed that bridge many years ago, so we shouldn't be giving any such people much more grief than we're already giving them. There have been non-upper-case-alpha abbreviations in the tz database since nearly day one. For example, in our repository the very first version of the 'europe' file (dated 1986) had spaces in some abbreviations, and spaces are much harder to parse than digits or plus signs are. In the current release, Pacific/Guam uses abbreviations that are not upper case alpha. Also, POSIX has blessed digits and plus signs in the abbreviations for quite some time; see <https://mm.icann.org/pipermail/tz/2001-January/011305.html>.
Matt Johnson wrote:
I'm more concerned with end-user confusion on whether +04 means GMT+04 or MSK+04.
No abbreviation will be confusion-free; all we have are imperfect alternatives. That being said, it seems unlikely that English-language users would naturally interpret "+04" to be relative to Moscow. In practice, I expect the more common mistake would be to interpret "+04" as being west of Greenwich instead of being east. For that, we'd just have to remind users that we're using the ISO standard for the sign. Surely "+04" would be more likely to be interpreted correctly than "AST" or "ASTT" or any other alphabetic abbreviation we might invent. Plus, numeric abbreviations generalize nicely to situations outside Russia, where we have similar issues.
On Sun, Feb 14, 2016, at 00:05, Paul Eggert wrote:
Matt Johnson wrote:
I'm more concerned with end-user confusion on whether +04 means GMT+04 or MSK+04.
No abbreviation will be confusion-free; all we have are imperfect alternatives.
Is there a strong reason to use +04 instead of UTC+04, other than a superficial resemblance to ISO 8601 offsets? How about "D"?
Random832 wrote:
Is there a strong reason to use +04 instead of UTC+04
Two reasons. First, UTC is undefined for time stamps before 1961. Second, "UTC+04" is longer than plain "+04". Although the latter objection is relatively minor, the former is fundamental. And although we could try working around the former objection by using "UTC+04" only for time stamps starting with 1961, we'd still need to address the problem for earlier time stamps somehow, and any solution we came up with would cause confusion for users wondering why different abbreviations are used before and after 1961. Brian Inglis suggested "+0400" as an alternative to "+04". This would also work, though it's longer. I plan to follow up on this in an email soon. Again, no abbreviation is perfect; even "UTC+04" would confuse some people about sign for the same reason that "+04" would. All in all, though, "+04" (or perhaps "+0400") seems like a better way to go than "UTC+04".
Random832 wrote:
How about "D"?
Under this proposal there is no "D" ("daylight") or "S" ("summer") in the abbreviation name. I view this as a feature, as often in these cases we are arbitrarily deciding whether the time is DST, and it's better to avoid inserting these inventions into tzdata when possible. We can't avoid this problem entirely (as tm_isdst needs *some* value) but the more we avoid making up stuff, the more reliable tzdata will be.
Random832 wrote:
I meant D as in the military name of UTC+04, not daylight.
Ah, sorry, I misunderstood. Single-letter names are too short to conform to POSIX (which requires at least 3 characters). Also, they are problematic on the net because Internet RFC 822 got them wrong (the sign was reversed). For this reason RFC 1123 says they "carry no information" in email Date: lines, and RFC 5322 says something similar. Also, single-letter names can't handle UTC offsets like +1400 and +0530 that are in practical use today. With all these problems I think we can safely exclude them from our bag of tricks.
Date: Sun, 14 Feb 2016 14:56:54 -0800 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <56C10636.4090905@cs.ucla.edu> | Random832 wrote: | > How about "D"? | | Under this proposal there is no "D" ("daylight") I think he meant to use exactly "D" as in the US Military zone name, not wanting a DST flag. Personally I'd prefer to the zone "abbreviations" (for all zones) were set to something like the function in the attached program prints (using tm_gmtoff for the zone - or what its value would be if it existed, in cases where it does not.) kre
participants (4)
-
Matt Johnson -
Paul Eggert -
Random832 -
Robert Elz