According to Kremlin press service,
Russian President Dmitry Medvedev signed a federal law "On calculation of time"
on June 9, 2011.
According to the law Russia is abolishing daylight saving time.
Medvedev signed a law "On the Calculation of Time" (in russian):
http://bmockbe.ru/events/?ID=7583
Medvedev signed a law on the calculation of the time (in russian):
http://www.regnum.ru/news/polit/1413906.html
Alexander Krivenyshev
http://www.worldtimezone.com
Hi,
Was working on strftime() and came across some info.
You may already have it but didn't see it in the current "g" files.
>From 29 December 2011, Samoa will advance its daylight savings time from UTC-10 to UTC+14 (and its standard time from UTC-11 to UTC+13), essentially moving the international date line to the other side of the country.
http://en.wikipedia.org/wiki/UTC%2B14:00
Might be worth a look?
Steve
I'm forwarding this message from Edward McGuire, who is not on the time zone mailing list.
Those of you who are on the list, please direct replies appropriately.
--ado
-----Original Message-----
From: metaed(a)gmail.com [mailto:metaed@gmail.com] On Behalf Of Edward McGuire
Sent: Friday, June 10, 2011 10:35
To: tz(a)lecserver.nci.nih.gov
Subject: correction for tz-link.htm 8.32
As requested at the top of the file, I am posting the following
correction for tz-link.htm 8.32, retrieved from
<ftp://ftp.irisa.fr/pub/OpenBSD/src/lib/libc/time/tz-link.htm>.
Under "Other time zone databases", the link labeled "Windows → Tzid
table" is
<http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html>,
which redirects to
<http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/windows_tzid.html>,
which is 404.
I guess this is the correction:
--- tz-link.htm 2011-06-10 09:31:20.734375000 -0500
+++ tz-link.new 2011-06-10 09:30:57.453125000 -0500
@@ -360,7 +360,7 @@
<li>Some Microsoft Windows versions contain time zone information in
an undocumented format, with IDs that can be mapped to <code>TZ</code>
values using the <a
-href="http://unicode.org/cldr/data/diff/supplemental/windows_tzid.html">Windows
+href="http://unicode.org/cldr/data/diff/supplemental/zone_tzid.html">Windows
→ Tzid table</a> maintained by the <abbr
title="Common Locale Data Repository">CLDR</abbr> data mentioned
below.</li>
Cheers,
MetaEd
On Jun 6, 2011, at 7:45 PM, Steven Abner wrote:
>
> On Jun 6, 2011, at 7:25 PM, Arthur Olson wrote:
>
>> Thanks for the message.
>>
>> 1. Hawaii hasn't used DST since the end of World War II,
>> which is why the Hawaiian zone ends with the lines...
>> -10:30 1:00 HDT 1945 Sep 30 2:00 #Schmitt&Fox+2
>> -10:30 - HST 1947 Jun 8 2:00 #Schmitt&Fox+2
>> -10:00 - HST
>> ...rather than your suggested...
>> -10:30 1:00 HDT 1945 Sep 30 2:00 #Schmitt&Fox+2
>> -10:30 US H%sT 1947 Jun 8 2:00 #Schmitt&Fox+2
>> -10:00 - HST
>> ...(although since there was no federally-mandated DST in the US from the end of
>> World War II until the 1960s, the effect is the same).
>>
>> 2. Since the current best guess is that Metlakatla hasn't used DST since 1983,
>> the last two lines of the Metlakatla zone should actually be...
>> -8:00 US P%sT 1983 Oct 30 2:00
>> -8:00 - MeST
>> ...without separate Metlakatla rules.
>>
>> --ado
>
> Thank you for responding!
> Hi
>
> I didn't suggest any change to Hawaii. That is a direct copy from your files tzdata2011g.
> As for Metlakatia I don't understand. I believe you are saying that "wiki" information, of the town, for the
> timezone is incorrect? Are you saying that they only observe STD and the abbreviated name is "MeST" ?
>
> Steve
>
sorry I should have added: http://en.wikipedia.org/wiki/Metlakatla,_Alaska
it it where I got no DST but alternating abbreviated names.
On May 18, 2011, at 8:02 AM, Steven Abner wrote:
>
> On May 15, 2011, at 8:59 PM, Olson, Arthur David (NIH/NCI) [E] wrote:
>
>> Your message indicates that you're using 2010 files; you may want to pick up...
>> ftp://elsie.nci.nih.gov/pub/tzdata2011g.tar.gz
>> ...which contains the most up-to-date information, then see how it compares with your information.
>
> Hi,
> I built your zic from tzcode2011d, used your tzdata2011g, and America/Metlakatla
> changed for dates in question (1983 - 2037), was "YST/AKST/AKDT", it now reports for both STD/DST "MeST" with alternating
> -8, -7 gmt offsets. From "wiki" it looks like it should be PST/AKDT with no alternating of gmt offsets.
> Best solution I can offer is(assuming its not "MeST/MeST" and this is what happened):
>
> # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
> Rule Metlak 1983 2006 - Oct lastSun 2:00 0 PS
> Rule Metlak 1984 1986 - Apr lastSun 2:00 0 AKD
> Rule Metlak 1987 2006 - Apr Sun>=1 2:00 0 AKD
> Rule Metlak 2007 max - Mar Sun>=8 2:00 0 AKD
> Rule Metlak 2007 max - Nov Sun>=1 2:00 0 PS
>
> Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 18
> -8:46:18 - LMT 1900 Aug 20 12:00
> -8:00 - PST 1942
> -8:00 US P%sT 1946
> -8:00 - PST 1969
> -8:00 US P%sT 1983 Oct 30 2:00
> -8:00 Metlak %sT
>
> with an alternate system, you can force alternating STD/DST, not sure how to get
> yours from STD/STD.
>
> For Europe/Sofia, I have at 2:00, you have at 3:00 on Sun Sep 26 1982.
> The Zone data states: 1982 Sep 26 2:00.
>
> For Atlantic/Canary, I have at 1:00, you have at 2:00 on Sun Sep 28 1980.
> The Zone data states: 1980 Sep 28 0:00s
>
> For Europe/Simferopol, I have the single date/time: Sun Mar 31 03:00:00 1996
> The file has two dates: Sun Mar 31 00:00:00 1996 and Sun Mar 31 04:00:00 1996
>
> For Asia/Phnom_Penh, Asia/Vientiane, Asia/Ho_Chi_Minh:
> I have Sat Mar 11 00:01:00 1911 and Wed May 1 00:00:00 1912
> The file yields Sun Mar 12 00:01:00 1911 and Thu May 2 00:00:00 1912
> Zone data has: 1911 Mar 11 0:01 and 1912 May.
>
> Something that doesn't show up on your files that I would like to verify, please, is
> For Zone America/Sitka you have -14:58:47 for LMT. Is that correct or should it be
> like other Alaska dates 14:58:47?
>
> Again, again, this is just questioning my accuracy or inaccuracy in creating a parser.
> I needed an alternate means of accessing your wonderfully gathered and created data.
>
> I would also like to see if you are open to possible changes to your data, some as simple as:
> changing a SAVE time 0:00 to 0, and others a little more complex like the Rule Metlak as above.
>
Hi again,
Since I hadn't heard back, I've decided to send you the alternative files. Your parser won't directly handle
the Europe file, as it follows the majority of your rules, but created a different exception, which should allow more
latitude for your rules, while hopefully simplifying exceptions in the parser unit. The "%" in front of "LETTER/S" signals
direct or literal replacement much like the "-" is to "RULES". The Europe file was also rearranged slightly to group
regions together for analysis.
Thanks again and hope these help.
Steve
Reference : From: Arthur David Olson <olsona <at> elsie.nci.nih.gov>
Subject: proposeed time zone package changes--Chile/Russia/Irkutsk/Buryatia/Morocco<http://news.gmane.org/find-root.php?message_id=%3c201103301402.p2UE2doP0127…>
Newsgroups: gmane.comp.time.tz<http://news.gmane.org/gmane.comp.time.tz>
Date: 2011-03-30 14:02:39 GMT (5 weeks, 1 day, 2 hours and 3 minutes ago)
Hi,
First of all, I have noticed that the proposed time change for Russia has not been applied to tzdata. Could you tell me when will this be done?
Second, this staying DST change is a bit confusing for me. Should it be that Russia will return to Russian Standard Time and will increase time zone offset by one ? But from the proposed change, the offset is not change. Am I missing something here?.
Lastly, I have seen the term of UTC+2 and UTC+2+1. For UTC+2+1, is it referring to time zone offset plus 2 with DST forward by one?
Your help is appreciated.
Regards,
Ren Wong
________________________________
"This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Technology or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: security(a)comverse.com. Thank You."
