7 regions in Russia submitted draft bills to change their time zones
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
Thanks very much for this summary of the status in Russia. It looks like we'll have our work cut out for us in the next several weeks. I hope that at some point the Duma or Council or President will say "no more changes this year", so that we can cut a release soon after that. But this is probably wishful thinking.
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
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
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".
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
Are we to carry this convention into other zones, and if so, what will we do for half-hour or 45-minute zones? 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? -Matt
To: wtz@worldtimezone.com; tz@iana.org From: eggert@cs.ucla.edu Date: Fri, 12 Feb 2016 13:53:56 -0800 Subject: Re: [tz] Astrakhan region got approval to change its time zone
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".
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.
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.
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. Samara is roughly a 17-hour nonstop drive north. That would be like people in San Diego thinking that they're on Portland time. All this SAMT / VLAT / etc. business is entirely our invention; it has little to do with how the Russians view time zones, or (more importantly) with how they are abbreviated in reliable English-language sources.
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 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 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
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.
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 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.
<<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 Fri, Feb 12, 2016, at 16:53, Paul Eggert wrote:
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".
AFAIK, Russian actual existing practice is to name relative to _Moscow_ time - I'd argue it should be MSK+1, and that all other Russian zones should be renamed likewise. AIUI historically the tz project has been hesitant to use names of the form [Name][+/-][Number] (such as UTC+04) because of the theory that someone might try to paste it directly into their timezone (the result of which is a timezone called UTC with offset -04:00)... maybe it should be re-examined whether this is sensible in today's environment.
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
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>.
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
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.
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 | +------------------+--------------------------+------------------------+
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/>
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/>
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 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
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.
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.
Russ Allbery wrote:
my sense is that it's much less common to use the two-digit form in day-to-day use of ISO 8601,
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...).
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.
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?
Random832 wrote:
Is there any way to use 6 digits _if_ the system supports at least seven characters, otherwise use some fallback value?
Not in the current tzdata format. The format allows more than 6 characters in the abbreviation, but it doesn't allow for varying formats depending on what the implementation supports. In practice for alignment reasons TZNAME_MAX is typically one less than a power of 2, when it's defined at all. The smallest value I've seen for it recently is 7, which means we would be OK with "+NNNNNN". In pre-2001 POSIX, TZNAME_MAX could be as small as 3, but those systems are obsolete now. This reminds me of another practical argument for brevity. In the current tzdata binary format, the total length of all abbreviations (including the terminating null byte for each one) cannot exceed 50. Currently one zone (Europe/Samara) is already at 49 and I expect that if we use 4-digit abbreviations we'd go over the limit soon. Although we can easily bump the limit to 256 in our own implementation, increasing it past 256 would require a nontrivial format change which would be a big deal. Also, possibly other implementations assume our current TZ_MAX_CHARS value of 50 (a mistake in my view, but there it is).
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
Oh, they'll ask! We get questions about *many* seemingly-minor details like this. And there is benefit to users of a consistent format across the timeline, independent of our not having to answer questions about seemingly-gratuitous changes.
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
True. However, the topics are not entirely separable as we use POSIX-style TZ strings in our binary output files. We can extend our binary-file TZ string format to include colon, but that would be a file format change which would be a cost. In practice my impression is that the colon is omitted more often than it's included and is not worth the hassle here.
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.
This is a different issue. It shouldn't be a problem with the current tzdata distribution, as none of the file names should disagree with the POSIX interpretation in the default installation.
where does "Local time zone must be set--see zic manual page" fit in to this discussion?
It's a grandfathered exception to the Theory guidelines for abbreviations.
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/>
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.
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
On Feb 15, 2016, at 2:11 PM, Derick Rethans <tz@derickrethans.nl> wrote:
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.
I suggest we have a program that grabs the PID and the time, seeds a random number generator from them, and randomly generates time zone abbreviations and checks them against all the existing abbreviations in the tzdb; as soon as it finds one that isn't already in the tzdb, it prints it. Use that to generate abbreviations for all new zones. 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.
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."
Hi, I agree with Karel. Abbreviations (even if invented) become common use and have a meaning for people who care about them and use them. 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. By the way, in case of Astrakhan, I would use SAMT without inventing any new abbreviation. Barbara On 16/feb/2016, at 10:24, Karel Volný <kvolny@redhat.com> wrote:
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
participants (15)
-
Alexander Krivenyshev -
Arthur David Olson -
Barbara Canino -
Brian Inglis -
Derick Rethans -
Garrett Wollman -
Guy Harris -
Karel Volný -
Lester Caine -
Matt Johnson -
Paul Eggert -
Paul Goyette -
Random832 -
Russ Allbery -
Tim Parenti