Alexander Krivenyshev <wtz <at> worldtimezone.com> writes:

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.

To make it easier to understand, below are the approximate phases of the

remaining regions requesting time zones changes:

- Sakhalin Oblast / Yuzhno-Sakhalinsk - Phase 1 (introduced to the State

Duma Council)

- Astrakhan Oblast / Astrakhan - Phase 2 ( first reading by the State Duma)

- Ulyanovsk Oblast / Ulyanovsk - Phase 1 (introduced to the State Duma

Council)

- Altai republic / Gorno-Altaysk - Phase 1 (introduced to the State Duma

Council)

- Altai Krai / Barnaul - Phase 1 (introduced to the State Duma Council)

- Magadan Oblast / Magadan - Phase 1 ( introduced to the Chairman of the

State Duma- part of the State Duma Council)

It is hard to say, how many above regions will be able to get through all

these phases and change their time zones by March 27, 2016.

We will try to keep our eyes on it.

Alexander Krivenyshev

http://www.worldtimezone.com

On February 10, 2016 Astrakhan Oblast got approval by the Federation Council to change its time zone to UTC+4 (from current UTC+3 Moscow time). http://asozd2.duma.gov.ru/work/dz.nsf/ByID/DE3C735A7CF5622743257F56004250F4/ $File/91250509-91280822.pdf?OpenElement Probably will be sign by the President in the next few days. Sakhalin Oblast is probably will be next- as of now in Phase 2 (first reading by the State Duma). Rest 4 regions (Magadan Oblast, Ulyanovsk Oblast, Altai republic / Gorno- Altaysk and Altai Krai / Barnaul) are at Phase 1 (introduced to the State Duma Council). Updated table (as of Feb 12, 2016) for all current regions in Russia that have submitted bills proposing changes to their time zones can be found on (use Google translate from Russian). http://www.worldtimezone.com/dst_news/dst_news_russia-2016-02-12.html Alexander Krivenyshev http://www.worldtimezone.com

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.

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.

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

Brian Inglis wrote:

It is not immediately apparent this is a zone "abbreviation", could be some kind of correction or a lat/long.

This format should be apparent in context. In a traditional date-time stamp such as POSIX C-locale 'date' output ("Mon Feb 15 03:18:46 +04 2016"), the "+04" is not reasonably interpreted to be a latitude or longitude. True, it might be interpreted to be a time correction; but that would be OK as it _is_ a time correction.

Without at least minutes and possibly also a colon, this does not look like a zone value.

POSIX does not allow a colon, but we could append minutes, e.g., "+0400" instead of "+04". Such a notation is widely used, e.g., Internet RFC 5322, which is used by this very email's "Date:" line (where "-0800" denotes my current time zone). ISO 8601 allows both "+04" and "+0400" (as well as "+04:00" and some other possibilities excluded by POSIX).

With more characters this may not fit within TZNAME_MAX limits, although looking around implementations there seems favour for 6.

POSIX requires that TZNAME_MAX must be at least 6, so we should be OK here. 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.

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

Paul Goyette wrote:

we should go ahead with the +0400 variant. At least this way, there'll be only one new variant for people to absorb!

We'll need multiple variants even if we avoid 2-digit offsets, as there have been time zones that were not integral multiples of a minute. The classic example is Liberia from 1919 through 1972, which was 44.5 minutes behind Universal Time. We could use a 6-digit offset for this abbreviation, i.e., "-004430"; this would go a bit beyond what ISO 8601 and POSIX allow, though. Such offsets are no longer in use, and the Liberia example need not impel us to use 6-digit offsets everywhere. By analogy, the existence of UT offsets like India's current "+0530" need not impel us to use 4-digit offsets everywhere.

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

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?

Lester Caine wrote:

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

...

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?

No; given the proposed patch, Astrakhan has not observed DST since October 2010. It just keeps changing its mind about its standard-time UTC offset.

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.

This is a feature more than it is a bug. Too often we invent the tm_isdst flag: that is, the flag is a property of tzdata that is in tzdata primarily because the database format requires a value for it. In these cases it's better to avoid propagating this invention into old-style time stamps like 'date' output in the C locale. This sort of thing is rarely an issue in well-settled locales typical of North America and western Europe, but it is a problem elsewhere, often in the regions where we don't want to be inventing abbreviations either.

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

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.

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

On 02/16/2016 07:19 AM, Random832 wrote:

I'm a bit uncomfortable with Russia being treated as a "second class citizen" of the timezone database The intent is not to treat Russia specially. I would like to remove all invented abbreviations from the database in due course, not just the invented Russian abbreviations. Europe/Astrakhan is first in this process only because it's a new zone, and removal of invented abbreviations is less likely to cause backwards-compatibility problems there. Assuming the experiment works well enough, the intent is to adopt the same practice with other zones both inside and outside Russia that have similar issues, e.g., Asia/Urumqi, Pacific/Kiritimati, America/Asuncion. Abbreviations like "XJT", "LINT", and "PET" are purely our invention and do not have reliable sources.

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.

On 02/16/2016 03:08 PM, Matt Johnson wrote:

Don't people in China use the term "Beijing Time"?

Yes, they use "北京时间" (Beijing Time, which we abbreviate as "CST" for China Standard Time because that's what we've done for decades), just as people in Russia use "Московское время" (which we abbreviate to MSK for even odder historical reasons). But Russia does not have standard names or abbreviations for anything other than Moscow time, and in this sense Russia is like China (though China is mostly a one-time-zone state so the problem of inventing abbreviations mostly does not come up there).

Even in the US, I think if you said "New York Time", people would know you meant Eastern.

Sure, and if you said "Houston Time" people would know you meant Central. But that doesn't mean the time zone is called "Houston Time" or is abbreviated "HOUT".

it would help to define the problem more clearly by understanding the current usage of these abbreviations. Where are they *actually* needed?

strftime's %Z format. This C-library interface is used by the 'date' command to get the time zone, and by lots of higher-level APIs, e.g., the current-time-zone function in GNU Emacs. There are other low-level C interfaces like tzname, but strftime %Z is the main thing.

In other words, in what use case(s) would I actually want to use abbreviations from TZDB instead of those from CLDR?

It depends on what you want to do. Ideally, you'd never want to use them in a new application. But legacy interfaces like strftime and current-time-zone must use them.

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.

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.