Paul Eggert <eggert <at> cs.ucla.edu> writes:

On 02/12/2016 11:29 AM, Alexander Krivenyshev wrote:

...

http://asozd2.duma.gov.ru/work/dz.nsf/ByID/DE3C735A7CF5622743257F56004250F4/

...

$File/91250509-91280822.pdf

Thanks for the heads-up. It looks like we'll need a new zone

Europe/Astrakhan, split off from the existing Europe/Volgograd. Will the

new zone will switch from UTC+3 on 2016-03-27 at 02:00, to UTC+4? This

detail is not in the above URL.

In the tz database, rather than give the new zone an invented

abbreviation like "ASTT" that does not correspond to existing practice,

I'd like to get out of the name-inventing business and just use "+04".

Yes, the switch will take into effect at 02:00am on 2016-03-27 Here is the link to the bill for the third reading- Project № 862646-6 (the Health Protection Committee of the State Duma) http://asozd2.duma.gov.ru/work/dz.nsf/ByID/5AEBD1A341D2B41843257F47003949EF/ $File/%D0%A2%D0%B5%D0%BA%D1%81%D1%82%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82% D0%B0_%D1%82%D1%80%D0%B5%D1%82%D1%8C%D0%B5%20%D1%87%D1%82%D0%B5%D0%BD%D0%B8% D0%B5.doc?OpenElement Google translation of the above document: Article 1 Write in part 1 of Article 5 of the Federal Law of June 3, 2011 № 107- FZ "On the Calculation of Time" (Collection of legislation of the Russian Federation, 2011, № 23, Article 3247;. In 2014, № 30, Article 4249;. 2016 Number 1, Art. 73) the following changes: 1) In paragraph 2, the words "Astrakhan region," shall be deleted; 2) Paragraph 3 after the words "Udmurtia" the words", the Astrakhan region." Article 2 This Federal Law shall enter into force on 27 March 2016 at 2 o'clock 00 minutes. Alexander Krivenyshev http://www.worldtimezone.com

On 02/12/2016 05:07 PM, Matt Johnson wrote:

Are we to carry this convention into other zones, and if so, what will we do for half-hour or 45-minute zones?

Yes, the idea is to experiment with this approach in the new zones (since they have no backwards-compatibility concerns) before using it in other zones. For non-hour zones I expect that we can use abbreviations like +05:45.

How do you feel about the RTZ1, RTZ2, etc. convention? Or the MSK+1, MSK+2, etc. convention that seems to actually be used in Russia?

tzdata is supposed to contain only English-language abbreviations. English text mostly just uses UTC offsets for these zones, except perhaps for "MSK". The other abbreviations are all purely our invention, if memory serves.

WRT abbreviation, Are we sure that Astrakhan actually needs to be identified with a *distinct* abbreviation? Though I agree that a new zone entry is required, it seems to me that the people living in the region will consider this as a move from Moscow time to Samara time. Perhaps it would be better just to model it as MSK before the switch, and SAMT after? -Matt -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Eggert Sent: Saturday, February 13, 2016 12:32 AM To: Time zone mailing list <tz@iana.org> Subject: Re: [tz] Astrakhan region got approval to change its time zone Paul Eggert wrote:

the idea is to experiment with this approach in the new zones (since they have no backwards-compatibility concerns) before using it in other zones.

Attached are two proposed patches along these lines. I haven't installed them into the experimental github repository, as I want to test some more first and get feedback. The second is merely a related commentary cleanup in zone*.tab.

On Tue, Feb 16, 2016, at 02:25, Paul Eggert wrote:

Matt Johnson wrote:

...

it seems to me that the people living in the region will consider this as a move from Moscow time to Samara time.

I really doubt whether they'll think they're on Samara time.

There would be a precedent in the fact that the Russian Wikipedia (which lists abbreviations, and doesn't 100% agree with us [USZ1 instead of EET for Kaliningrad]) doesn't recognize NOVT, but instead calls the whole UTC+6/MSK+3 timezone "OMST". Worldtimezone.com, incidentally, has a list of _names_ (not associated with abbreviations, the abbreviations given are simply USZ1 through UZ11), with no clear source but different from ours: - Kaliningrad Time - Moscow Time - Volga Time - Ural Time - West-Siberian Time - Yenisei Time - Irkutsk Time - Amur Time - Vladivostok Time - Okhotsk Time - Kamchatka Time I'm a bit uncomfortable with Russia being treated as a "second class citizen" of the timezone database just because people don't often write times there in English.

On 16 February 2016 at 02:25, Paul Eggert <eggert@cs.ucla.edu> wrote:

I really doubt whether they'll think they're on Samara time. Samara is roughly a 17-hour nonstop drive north. That would be like people in San Diego thinking that they're on Portland time.

That's not a particular obstacle; we already use SAMT for the Udmurt Republic as well, and Samara is an 8-hour drive south of its largest city, Izhevsk. The two areas aren't contiguous as it is; adding a third would not seem to be a concern. On 16 February 2016 at 11:37, Paul Eggert <eggert@cs.ucla.edu> wrote:

I would like to remove all invented abbreviations from the database in due course, not just the invented Russian abbreviations.

I agree with the general sentiment I've seen here a few times that, e.g., "UTC+0400" is preferable to "+0400" which is preferable to "+04"; the latter are wholly redundant with the "%z" and "%:::z" format strings offered by date, so I see no good reason to manually encode that data a second time as strings. If we want to "get out of the abbreviation business," I think that's an argument for improving our toolchain accordingly, rather than shoving this into the legacy system. Insofar as SAMT is already a perfectly good (albeit invented) abbreviation for this purpose, 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. -- Tim Parenti

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.

I don't think it's so unheard of. Don't people in China use the term "Beijing Time"? Even in the US, I think if you said "New York Time", people would know you meant Eastern.

...

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.

I can't speak for everyone, but my preference would be for consistency across all entries. While it may seem to have less impact to only do this for new zones, that doesn't relieve library authors, platform vendors, etc. from having to contend with both sets of data. Also, it would help to define the problem more clearly by understanding the current usage of these abbreviations. Where are they *actually* needed? In other words, in what use case(s) would I actually want to use abbreviations from TZDB instead of those from CLDR? What would be the consequence of just removing the column entirely? (ok, maybe too drastic, but just for discussion)

<<On Tue, 16 Feb 2016 16:26:43 -0800, Paul Eggert <eggert@cs.ucla.edu> said:

...

What would be the consequence of just removing the column entirely? (ok, maybe too drastic, but just for discussion)

strftime %Z would stop working, and lots of old and/or questionable code would stop working.

And a few million people who live in areas where these abbreviations matter would get rightly pissed off, although it might take them a while to notice, because the vendors would probably fork tzdata at that point rather than deal with the hassle. -GAWollman

On 2016-02-12 14:53, Paul Eggert wrote:

On 02/12/2016 11:29 AM, Alexander Krivenyshev wrote:

...

http://asozd2.duma.gov.ru/work/dz.nsf/ByID/DE3C735A7CF5622743257F56004250F4/ $File/91250509-91280822.pdf Thanks for the heads-up. It looks like we'll need a new zone Europe/Astrakhan, split off from the existing Europe/Volgograd. Will the new zone will switch from UTC+3 on 2016-03-27 at 02:00, to UTC+4? This detail is not in the above URL.

In the tz database, rather than give the new zone an invented abbreviation like "ASTT" that does not correspond to existing practice, I'd like to get out of the name-inventing business and just use "+04".

I just know a bunch of people out there are cluelessly checking this string is upper case alpha. How about just following existing practice to avoid breakage and screams, be lazy and use A%sT. ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

On 2016-02-13 19:02, Paul Eggert wrote:

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>.

Never saw much benefit in innovating meaningless abbreviations to be less ambiguous. Localization requires knowing the language, territory, script, character set, and zone to be useful. It is not immediately apparent this is a zone "abbreviation", could be some kind of correction or a lat/long. Without at least minutes and possibly also a colon, this does not look like a zone value. Signed numbers could be either US/POSIX or ISO signs. With more characters this may not fit within TZNAME_MAX limits, although looking around implementations there seems favour for 6. The intent would be more obvious with a UTC or MSK prefix, and that may have been what POSIX wanted to allow. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

On Sun, 14 Feb 2016, Paul Eggert wrote:

The attached additional patch would change the new zone to use "+0400" rather than "+04". Still, I mildly prefer "+04", as it's briefer. No matter what we switch to, we will confuse some people; and other things being roughly equal, briefer is better.

Perhaps briefer is better. But if this is a "trial run" for moving into the future, where we can reasonably expect partial hour offsets, we should go ahead with the +0400 variant. At least this way, there'll be only one new variant for people to absorb! Just my PHP 1 (approx. USD 0.02) worth of opinion! +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+

Slightly outside the box: for long-ago times, "LMT" is used to cover a multitude of cases; "LST" (Local Standard Time) (in some cases, in conjunction with "LDT") could used for all those (new) cases where an abbreviation isn't known. (Alternately, just "LOCAL"could be used rather than "LST" and "LDT", avoiding a conflict with Latvian Standard Time.) @dashdashado On Sun, Feb 14, 2016 at 9:48 PM, Russ Allbery <eagle@eyrie.org> wrote:

Paul Goyette <paul@whooppee.com> writes:

...

On Sun, 14 Feb 2016, Paul Eggert wrote:

...

...

The attached additional patch would change the new zone to use "+0400" rather than "+04". Still, I mildly prefer "+04", as it's briefer. No matter what we switch to, we will confuse some people; and other things being roughly equal, briefer is better.

...

Perhaps briefer is better. But if this is a "trial run" for moving into the future, where we can reasonably expect partial hour offsets, we should go ahead with the +0400 variant. At least this way, there'll be only one new variant for people to absorb!

...

Just my PHP 1 (approx. USD 0.02) worth of opinion!

Yeah, that's my personal leaning as well. Another useful principle along the lines of "briefer is better" is "don't invent new notation if one can avoid it." Using the existing ISO 8601 time zone notation for the time zone abbreviation has a lot of merit under that principle. Anyone familiar with ISO 8601 or RFC 822 syntax will immediately find it familiar.

(It's worth noting that +04 is also valid ISO 8601, which weakens this argument, but my sense is that it's much less common to use the two-digit form in day-to-day use of ISO 8601, and it's intended to indicate lower precision. ISO 8601 allows a lot of abbreviated forms that, in practice, one usually doesn't use because they just add confusion without serving much purpose.)

-- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>

On 15/02/16 09:07, Paul Eggert wrote:

Arthur David Olson wrote:

...

"LST" (Local Standard Time) (in some cases, in conjunction with "LDT") could used for all those (new) cases where an abbreviation isn't known.

This would be less useful for traditional time stamps. For example, the output of successive invocations of POSIX 'date' in the C locale in Astrakhan might look like this:

Tue Jul 1 12:31:27 LST 2014 Mon Feb 15 03:18:46 LST 2016 Sat Jul 1 23:51:21 LST 2017 Presume you meant LDT for July?

and information about the UT offset would be lost. In contrast, using +NN would case 'date' output to look like this:

Tue Jul 1 12:31:27 +04 2014 Mon Feb 15 03:18:46 +03 2016 Sat Jul 1 23:51:21 +04 2017

and the UT offset info would be available. The one thing I still find a major problem is the fact that dates which involve a daylight saving element are not easy to identify. The fact that we STILL only have a UT offset from the browser means that moving that Febuary meeting to April one has no idea if there should be an hour switch ... or not ... At least if the abbreviation can be identified as part of a DST pair one know to look up the switch dates. If there is no DST element, then +nn *IS* all that is needed? But perhaps an additional S or D if the offset involves a DST rule set?

-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Why not using SAMT (Samara Time)? If I'm not wrong, the Samara Oblast doesn't seem to be planning to change time zone. If Samara doesn't belong to the 6 additional regions that have requested to change their time zones (see end of quotation below), we could then use the same abbreviation for the Ulyanovsk Oblast as well. On 03/gen/2016, at 06:14, Alexander Krivenyshev <wtz@worldtimezone.com> wrote:

After researching several official government documents (duma.gov.ru), there are at least 7 regions in Russia (not 3) that have submitted draft bills proposing changes to their time zones.

Those regions are:

- Zabaykalsky Krai / Chita (draft bill date of entry July 16, 2015)- has recently received approval to change time zone from UTC+8 to UTC+9

- Astrakhan Oblast / Astrakhan (draft bill date of entry Aug. 15, 2015), UTC+3 to UTC+4

- Sakhalin Oblast / Yuzhno-Sakhalinsk (draft bill date of entry Sep. 28, 2015), UTC+10 to UTC+11

- Ulyanovsk Oblast / Ulyanovsk (draft bill date of entry Nov. 03, 2015), UTC+3 to UTC+4

- Altai republic / Gorno-Altaysk (draft bill date of entry Nov. 23, 2015), UTC+6 to UTC+7

- Altai Krai / Barnaul (draft bill date of entry Dec. 03, 2015), UTC+6 to UTC+7

- Magadan Oblast / Magadan (draft bill date of entry Dec. 08, 2015), UTC+10 to UTC+11

See as a reference Russia map with 7 regions to change their time zones (darker colors of blue, green, red):

http://www.worldtimezone.com/russia-time-zones-map-2016-04.gif

(vs current http://www.worldtimezone.com/time-russia12.php)

Seems that draft bill in Russia must pass through the following phases before being signed into law:

Phase 1- The State Duma Council draft bill review

Phase 2- Pass three (3) readings/revisions by the State Duma

Phase 3- Approval by the Federation Council

Phase 4- Signed by the President.

Currently there are 6 additional regions in Russia that have requested to change their time zones (make amendments to the current Federal Law "On the calculation of time"), those draft bills were introduced at different times and are in different phases of the approval (or rejection) process.

On Mon, Feb 15, 2016, at 04:05, Paul Eggert wrote:

Yes, I have the same sense. This is the main argument for having 4 digits in the offset. I also have the sense that 4 digits have been quite a bit more popular in this thread (though I'm not sure how we'd handle Liberia before 1972 -- maybe give up and leave that one alphabetic...).

Is there any way to use 6 digits _if_ the system supports at least seven characters, otherwise use some fallback value? (Maybe "-0044~" - which could be generalized as replacing the sixth and onward character with ~ which can be read as meaning imprecision... or, simply "XXXXXX" if you don't like that.) It'd also be nice to use "UTC+NN:NN" if the system allows at least nine characters, "+NN:NN" [or UTC+NN when there are no minutes] otherwise (and, in Liberia's case, UTC-00:44:30/-00:44:30/-0044~ for 12/9/6 respectively) - perhaps store the most verbose form in the database, and have a defined series of transformations (remove colon, remove trailing :00's if they don't fit, remove UTC/GMT if it doesn't fit, remove colons if they don't fit and we didn't already, etc) based on TZNAME_MAX and a compile-time option for whether POSIX is strictly interpreted to not allow including colons. I also don't understand the objection to using UTC+XX or UTC+XXXX (the latter when there is enough space for it) - if it's really important not to use the term "UTC" for values from before 1961, then use GMT. I absolutely don't understand the objection "any solution we came up with would cause confusion for users wondering why different abbreviations are used before and after 1961." If anyone asks - if anyone even notices anything at all for timezones so far outside the range of what they encounter daily - it can be easily explained to them. I'd also like to note that the example cited in _your_ announcement of the new POSIX feature allowing plus signs in TZ was '<UTC+10>-10'. I also don't think that POSIX's limitation of not allowing a colon in TZ should necessarily be generalized to not allowing a system to provide a colon (or tilde, etc) in a timezone abbreviation set by a non-POSIX-format TZ value. It's a limitation on the format of the TZ environment variable, not the contents of the abbreviation fields (which are set in an implementation-defined manner for TZ=:characters, and unspecified where "either field is less than three bytes (except for the case when dst is missing), more than {TZNAME_MAX} bytes, or if they contain characters other than those specified.") Frankly, I'd be more worried about zones like "EST5EDT", and tz's practice of A) allowing TZ to name a file without a leading colon and B) not giving preference to the POSIX interpretation [so these files would never get hit] when such a file is found. Also, where does "Local time zone must be set--see zic manual page" fit in to this discussion?

Paul Eggert <eggert@cs.ucla.edu> writes:

Russ Allbery wrote:

...

and it's intended to indicate lower precision.

I don't have this sense for 2-digit zones. I would not expect (and have never seen) India's time zone being listed as "+06" because someone felt like rounding +0530 up.

Oh, sorry, they changed this between the 1993 and 1998 versions of ISO 8601 and I didn't think to check the later version since the 1993 version was closer at-hand. The 1993 edition says: Omitting the minutes implies a lower precision for the time zone value, and is independent of the time value to which the zone is attached. but that language appears to be gone in the 1998 edition. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>

On Fri, 12 Feb 2016, Paul Eggert wrote:

On 02/12/2016 11:29 AM, Alexander Krivenyshev wrote:

...

http://asozd2.duma.gov.ru/work/dz.nsf/ByID/DE3C735A7CF5622743257F56004250F4/ $File/91250509-91280822.pdf Thanks for the heads-up. It looks like we'll need a new zone Europe/Astrakhan, split off from the existing Europe/Volgograd. Will the new zone will switch from UTC+3 on 2016-03-27 at 02:00, to UTC+4? This detail is not in the above URL.

In the tz database, rather than give the new zone an invented abbreviation like "ASTT" that does not correspond to existing practice, I'd like to get out of the name-inventing business and just use "+04".

My main concern with stopping to use only upper case ASCII letters is that is going to break many implementations. Is it really worth the risk of deviating from this unwritten rule? Data stability is important, please do not take the decision of moving away from the defacto standard of upper case ASCII letters lightly. lightly. cheers, Derick -- PHP's Date/Time maintainer

Hi,

And, yes, I am at least half serious, if not more. Expecting the tzdb maintainers to pick abbreviations for regions from which I suspect most of us don't come, and speaking languages that I suspect most of us don't speak, and have them be somehow appropriate is probably unwise.

I wouldn't be that pesimistic ... for example, in my country (Czech Republic), "CET" and "CEST" fit pretty well as we do use "středoevropský (letní) čas" which isn't that hard to associate and understand as it translates exactly as "Central European (Summer) Time" if we are aware that Russia is used to "Москва+X", why not go with "MSK+??" (except for breaking backwards compatibility as different names were invented in the past) if we are unaware ... well, I don't see how inventing something that could be understood at least in English, if not for locals, makes the situation any worse than using random string sorry, I'm a bit late to the party, so I may have missed something (links to archives welcome), but I can't understand what problem are we trying to solve now? - the zone name is completely irrelevant to software, it is to help people, and for me (not statistically significant, right? :-)) it is thousands times better to read "CET" or "CEST" than "+01" and "+02" respectively K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol@jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."

On 16/02/16 11:56, Barbara Canino wrote:

In addition to that, I would like to point out that introducing strings like "+04", "+0400", "UTC+04", "UTC+0400" instead of abbreviations is providing information that is already available: programs can easily calculate and display any of the strings above using the GMT offsets available in tz files.

BUT you need to know the location as part of the time to do that ... If you send me 12:00 UTC+04 then I know both current local time and UTC time, but I don't know the local time offset 6 months from now. My problem and the reason I started taking an interest in tz is that data which has been normalised to UTC in the past is now useless because we have no reference to just what rules were used. Even today there is no easy way of establish if a diary normalised to UTC is using DST rules that have changed recently. Having a unique abbreviation is not the solution either, but may at least flag the potential problem. Moving forward, being able to identify both the rule used and the version of that rule is essential for SOME areas of calendering. One can get away with short cuts some of the time, but once the data becomes archived, being able to work with it later may be a problem if the version of tz (warts and all) is not identifiable. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk