- tz - lists.iana.org

Bill to return Russia 11 time zones
by Alexander Krivenyshev July 22, 2014

July 22, 2014

According to the Russian news (ITAR-TASS News Agency) http://en.itar-tass.com/russia/738562 The State Duma has approved in the second and third, the last reading the draft bill on returning to winter time standard and return Russia 11 time zones. The new regulations will come into effect on October 26, 2014 at 02:00 Moscow time. http://www.worldtimezone.com/dst_news/dst_news_russia62.html Alexander Krivenyshev http://www.WorldTimeZone.com

4 9

[PATCH 0/5] Further fixes for Russian time zone changes
by Paul Eggert July 22, 2014

July 22, 2014

Here are some more patches to the tz database to cover the proposed time zone changes in Russia. The basic idea is to not do anything drastic like add new zones until the Russian changes are finalized, but in the meantime to assume that the changes will probably happen and to update existing zones accordingly. Much of the work in generating these patches was by Tim Parenti. Thanks! Paul Eggert (1): Update zone.tab for Russia, and remove Asia/Tiksi comment. Tim Parenti (4): Further fixes for the proposed Russian change on 2014-10-26. Prefer MSK/MSD for Volgograd when on Moscow time. Standardize commentary on the coverage of each Russian zone. Zone splits for the proposed Russian change on 2014-10-26 NEWS | 31 ++++- europe | 455 ++++++++++++++++++++++++++++++++++++++++++++++++--------------- zone.tab | 16 ++- 3 files changed, 386 insertions(+), 116 deletions(-) -- 1.9.1

2 6

Fwd: Proposal to use 1946-01-01 instead of 1970-01-01 as cutoff point
by Tobias Conradi July 20, 2014

July 20, 2014

Retry, this didn't go through 2013-09-06, due to blocking by the time zone mailing list maintainer. ---------- Forwarded message ---------- From: Tobias Conradi <mail.2012(a)tobiasconradi.com> Date: Fri, Sep 6, 2013 at 12:11 PM Subject: Proposal to use 1946-01-01 instead of 1970-01-01 as cutoff point To: "tz(a)iana.org mailing list" <tz(a)iana.org> Proposal to use 1946-01-01 instead of 1970-01-01 as cutoff point. The concept of country in the database is based on ISO 3166 standards. ISO at http://www.iso.org/iso/home/standards/country_codes.htm says: "The country names in ISO 3166 come from United Nations sources." http://www.un.org/en/aboutun/index.shtml says: "The United Nations is an international organization founded in 1945" So 1946 is the first year where on 1 January the UN existed. This new boundary would exclude to reject data improvement requests like http://mm.icann.org/pipermail/tz/2010-January/016007.html Rejection: http://mm.icann.org/pipermail/tz/2010-January/016010.html Apart from allowing easier inclusion of historic data, the new cutoff point might be easier understandable by most users, assuming the UN is more known than Unix. The new cutoff point is located after WW2 end, thus inclusion of war time offset changes is still not mandatory. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Fwd: [PATCH] New file time.tab, superseding zone.tab
by Tobias Conradi July 20, 2014

July 20, 2014

looks list related, didn't read. Please everybody email to the list, not to me. ---------- Forwarded message ---------- From: John Hawkinson <jhawk(a)mit.edu> Date: Sun, Jul 20, 2014 at 4:36 AM Subject: Re: [tz] [PATCH] New file time.tab, superseding zone.tab To: Tobias Conradi <tc(a)tobiasconradi.com> Tobias: This message is sent to you personally and I expect you not to forward it to the list. Forwarding it to the list is probably reasonable grounds for the list management to ban you from the list again. Tobias Conradi <tc(a)tobiasconradi.com> wrote on Sun, 20 Jul 2014 at 04:20:02 +0200 in <CAAGevbXDN84607k_hSz93PXWB4uBhQgNuVP5z487b-+pRaCzPw(a)mail.gmail.com>: > This message seems list related but what only send to me. Maybe it is > of interest to others, as it gives insights into how Paul Eggert is > managing the list. It just tells us that Paul was doing the right thing, and that both of your messages were inappropriate. The first one, and then this second one as well. Paul would be justified in banning you from the list because of this, and I think he should. You have clearly shown you have poor judgement and poor understanding of list etiquette, and Paul has been patient with you. To be perfectly clear, your forwarding Paul's message is a violation of etiquette and further demonstrates that you should not be sending email to the list. Hopefully you can enforce that yourself, rather than needing to ban you via administrative/technical means. --jhawk(a)mit.edu John Hawkinson > > On Sun, Jul 20, 2014 at 4:12 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > > Tobias Conradi wrote: > >> > >> Paul Eggert controls ids, removes > >> them, repurposes them as he likes. > > > > > > I'm going to ask you again, privately, to stop making personal comments like > > that. This sort of thing out of place in this mailing list. If you can't > > refrain from putting personal comments into your email, then you should not > > be sending email to the list. > > > > -- > Tobias Conradi > Rheinsberger Str. 18 > 10115 Berlin > Germany > > http://tobiasconradi.com -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

Bug report for the tzcode2014e.tar.gz, patch included.
by John Cochran July 20, 2014

July 20, 2014

Greetings, I was recently working on an open source project seeing about updating some code based upon the 2010c version of your timezone code and bringing the code up to date based upon your 2014e version. In the process of doing this, I noticed some unneeded object files being linked together in order to create the zic program. As specified by your Makefile, zic is comprised of zic.o, localtime.o, asctime.o, scheck.o, and ialloc.o But as it turns out, localtime.o doesn't supply any symbols that zic.o needs. Additionally, the inclusion of asctime.o is there in order to satisfy a linkage requirement for localtime.o. So zic can be built by linking only zic.o, scheck.o, and ialloc.o together. A context diff of the proposed fix is attached. Sincerely, John Cochran -- There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. — C.A.R. Hoare

2 1

Re: [tz] [PATCH] New file time.tab, superseding zone.tab
by Tobias Conradi July 20, 2014

July 20, 2014

This message seems list related but what only send to me. Maybe it is of interest to others, as it gives insights into how Paul Eggert is managing the list. On Sun, Jul 20, 2014 at 4:12 AM, Paul Eggert <eggert(a)cs.ucla.edu> wrote: > Tobias Conradi wrote: >> >> Paul Eggert controls ids, removes >> them, repurposes them as he likes. > > > I'm going to ask you again, privately, to stop making personal comments like > that. This sort of thing out of place in this mailing list. If you can't > refrain from putting personal comments into your email, then you should not > be sending email to the list. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

[PATCH] * europe, NEWS: Give proper credit to George Vernon Hudson
by Paul Eggert July 19, 2014

July 19, 2014

as the inventor of DST. --- NEWS | 2 ++ europe | 20 +++++++++++++++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index babfdac..1845ee8 100644 --- a/NEWS +++ b/NEWS @@ -186,6 +186,8 @@ Unreleased, experimental changes There is new commentary about time in Poland in 1919. + Proper credit has been given to DST inventor George Vernon Hudson. + Commentary about time in Metlakatla, AK and Resolute, NU has been improved, with a new source for the former. diff --git a/europe b/europe index 2ba3493..e87cc21 100644 --- a/europe +++ b/europe @@ -137,8 +137,22 @@ # transition date for London, namely 1847-12-01. We don't know as much # about Dublin, so we use 1880-08-02, the legal transition time. -# From Paul Eggert (2003-09-27): -# Summer Time was first seriously proposed by William Willett (1857-1915), +# From Paul Eggert (2014-07-19): +# The ancients had no need for daylight saving, as they kept time +# informally or via hours whose length depended on the time of year. +# Daylight saving time in its modern sense was invented by the +# New Zealand entomologist George Vernon Hudson (1867-1946), +# whose day job as a postal clerk led him to value +# after-hours daylight in which to pursue his research. +# In 1895 he presented a paper to the Wellington Philosophical Society +# that proposed a two-hour daylight-saving shift. See: +# Hudson GV. On seasonal time-adjustment in countries south of lat. 30 deg. +# Transactions and Proceedings of the New Zealand Institute. 1895;28:734 +# http://rsnz.natlib.govt.nz/volume/rsnz_28/rsnz_28_00_006110.html +# Although some interest was expressed in New Zealand, his proposal +# did not find its way into law and eventually it was almost forgotton. +# +# In England, DST was independently reinvented by William Willett (1857-1915), # a London builder and member of the Royal Astronomical Society # who circulated a pamphlet "The Waste of Daylight" (1907) # that proposed advancing clocks 20 minutes on each of four Sundays in April, @@ -151,7 +165,7 @@ # A monument to Willett was unveiled on 1927-05-21, in an open space in # a 45-acre wood near Chislehurst, Kent that was purchased by popular # subscription and open to the public. On the south face of the monolith, -# designed by G. W. Miller, is the...William Willett Memorial Sundial, +# designed by G. W. Miller, is the William Willett Memorial Sundial, # which is permanently set to Summer Time. # From Winston Churchill (1934-04-28): -- 1.9.1

1 0

WG Review: Time Zone Data Distribution Service (tzdist)
by The IESG July 18, 2014

July 18, 2014

A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-28. Time Zone Data Distribution Service (tzdist) ------------------------------------------------ Current Status: Proposed WG Assigned Area Director: Barry Leiba <barryleiba(a)computer.org> Mailing list Address: tzdist(a)ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/tzdist Archive: http://www.ietf.org/mail-archive/web/tzdist/ Charter: Time Zone Data Distribution Service (tzdist) ----------------------------------------------------------- A time zone is a region that has a uniform local time for legal, commercial, and social purposes, with some regions using daylight saving time (DST) rules for part of the year. A local time is defined as a standard offset from Coordinated Universal Time (UTC), and a set of DST rules. Time zone data represents the history, current, and future local time rules for these regions, together with an associated time zone identifier. Time zone data is a critical element of computer systems and devices that make use of local time. In particular, it is critical to any calendaring and scheduling system, such as iCalendar (RFC 5545). Daylight saving time rules, which affect local UTC offsets, can change - sometimes at very short notice (just a few days) - as those rules are typically defined by political processes. Currently, there is no efficient, fast way to ensure that time zone data is updated in a timely and reliable manner on devices that need it. Time zone changes are often delivered as operating system updates, and are thus tied to release schedules that can trail the actual time zone changes by a significant period of time. A service is needed that can provide timely, reliable updates. One added benefit of such a service for iCalendar is the ability for calendaring clients and servers to agree on common, standard definitions of time zone data, removing the need to pass time zone data directly "by value" in iCalendar data. By allowing clients and servers to use time zones "by reference" significant network bandwidth and storage savings can be achieved. This working group will: - Define a time zone data distribution protocol that allows for efficient, timely updates of time zone data to be delivered to clients. This protocol must scale to vast numbers of clients, such as the potential "internet of things" devices, as well as to today's desktop computers and servers. - Define an extension to CalDAV (RFC 4791) to allow clients and servers to use time zones "by reference" to improve the efficiency of the overall protocol. The working group will use the following drafts as initial input for its work: draft-douglass-timezone-service-11 draft-daboo-caldav-timezone-ref-01 The working group will work under the following parameters: - The time zone data distribution protocol will initially be targeted at iCalendar-based clients, but should be flexible enough to deliver time zone data in other formats. - The time zone data will be based on the Time Zone Database (http://www.iana.org/time-zones) but must be able to include any source of time zone data. - The time zone data distribution protocol should also offer an API to allow thin clients to easily make use of time zone data by querying for UTC offsets, offloading the sometimes complex work of expanding recurrence rules to the service. This API should be extensible to support other types of time zone operations in the future. - The time zone data distribution protocol will use current security protocols to protect the integrity and confidentiality of the data as it is distributed, and may also address these issues with respect to retrieval of data from its original source (such as the Time Zone Database). Even public time zone data can represent a significant privacy exposure when it is associated with the user or endpoint that is retrieving it. The following are Out of scope for the working group: - Any changes to the Time Zone Database process or infrastructure, as documented in RFC 6557. However, the WG may work with IANA in order to make integrity checking information, such as public keys, readily accessible for protocol use. - The naming process for time zone identifiers. The working group can consider adding a mechanism, such as a "namespace" prefix, to differentiate different time zone sources, but the nature of the time zone identifiers used will be controlled by the sources themselves. - Lookup protocols or APIs to map a location to a time zone. Milestones: TBD

1 0

[PATCH] Be a bit more consistent about Metlakatla and Resolute abbr and comments.
by Paul Eggert July 18, 2014

July 18, 2014

* northamerica (America/Metlakatla): Use the more-common "PST" rather than our invented "MeST" for the abbreviation. Our source called it "Pacific Time", as did a contemporaneous news report, and I couldn't find contemporaneous use of "MeST" or of "Metlakatla Time". Cite the news report in the commentary, and quote some Juneau graffiti. * zone.tab (America/Resolute): Call it Central Time, not Central Standard Time, since it observes DST now. (America/Metlakatla): Call it Pacific Standard Time, not Metlakatla Time. Mention that it's in Alaska. * NEWS: Document the above. --- NEWS | 5 +++++ northamerica | 17 +++++++++++------ zone.tab | 4 ++-- 3 files changed, 18 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index f77fe86..ffcbd92 100644 --- a/NEWS +++ b/NEWS @@ -46,6 +46,8 @@ Unreleased, experimental changes Prefix "W" to (western) Samoa time when its standard-time offset disagrees with that of American Samoa. + America/Metlakatla now uses PST, not MeST, to abbreviate its time zone. + Time zone abbreviations have been updated for Japan's two time zones used 1896-1937. JWST now stands for Western Standard Time, and JCST for Central Standard Time (formerly this was CJT). @@ -173,6 +175,9 @@ Unreleased, experimental changes There is new commentary about time in Poland in 1919. + Commentary about time in Metlakatla, AK and Resolute, NU has been + improved, with a new source for the former. + In zone.tab, Pacific/Easter no longer mentions Salas y Gómez, as it is uninhabited. diff --git a/northamerica b/northamerica index c461ef4..1b6bb23 100644 --- a/northamerica +++ b/northamerica @@ -421,13 +421,18 @@ Zone America/Los_Angeles -7:52:58 - LMT 1883 Nov 18 12:07:02 # was destroyed in 1805 by a Yakutat-kon war party.) However, there # were nearby inhabitants in some cases and for our purposes perhaps # it's best to simply use the official transition. -# -# From Steve Ferguson (2011-01-31): -# The author lives in Alaska and many of the references listed are only -# available to Alaskan residents. +# From Paul Eggert (2014-07-18): +# One opinion of the early-1980s turmoil in Alaska over time zones and +# daylight saving time appeared as graffiti on a Juneau airport wall: +# "Welcome to Juneau. Please turn your watch back to the 19th century." +# See: Turner W. Alaska's four time zones now two. NY Times 1983-11-01. +# http://www.nytimes.com/1983/11/01/us/alaska-s-four-time-zones-now-two.html # -# http://www.alaskahistoricalsociety.org/index.cfm?section=discover%20alaska&… +# Steve Ferguson (2011-01-31) referred to the following source: +# Norris F. Keeping time in Alaska: national directives, local response. +# Alaska History 2001;16(1-2). +# http://alaskahistoricalsociety.org/discover-alaska/glimpses-of-the-past/kee… # From Arthur David Olson (2011-02-01): # Here's database-relevant material from the 2001 "Alaska History" article: @@ -489,7 +494,7 @@ Zone America/Metlakatla 15:13:42 - LMT 1867 Oct 18 -8:00 US P%sT 1946 -8:00 - PST 1969 -8:00 US P%sT 1983 Oct 30 2:00 - -8:00 - MeST + -8:00 - PST Zone America/Yakutat 14:41:05 - LMT 1867 Oct 18 -9:18:55 - LMT 1900 Aug 20 12:00 -9:00 - YST 1942 diff --git a/zone.tab b/zone.tab index e29778c..e415ca6 100644 --- a/zone.tab +++ b/zone.tab @@ -128,7 +128,7 @@ CA +4901-08816 America/Nipigon Eastern Time - Ontario & Quebec - places that did CA +4823-08915 America/Thunder_Bay Eastern Time - Thunder Bay, Ontario CA +6344-06828 America/Iqaluit Eastern Time - east Nunavut - most locations CA +6608-06544 America/Pangnirtung Eastern Time - Pangnirtung, Nunavut -CA +744144-0944945 America/Resolute Central Standard Time - Resolute, Nunavut +CA +744144-0944945 America/Resolute Central Time - Resolute, Nunavut CA +484531-0913718 America/Atikokan Eastern Standard Time - Atikokan, Ontario and Southampton I, Nunavut CA +624900-0920459 America/Rankin_Inlet Central Time - central Nunavut CA +4953-09709 America/Winnipeg Central Time - Manitoba & west Ontario @@ -433,7 +433,7 @@ US +571035-1351807 America/Sitka Alaska Time - southeast Alaska panhandle US +593249-1394338 America/Yakutat Alaska Time - Alaska panhandle neck US +643004-1652423 America/Nome Alaska Time - west Alaska US +515248-1763929 America/Adak Aleutian Islands -US +550737-1313435 America/Metlakatla Metlakatla Time - Annette Island +US +550737-1313435 America/Metlakatla Pacific Standard Time - Annette Island, Alaska US +211825-1575130 Pacific/Honolulu Hawaii UY -3453-05611 America/Montevideo UZ +3940+06648 Asia/Samarkand west Uzbekistan -- 1.9.1

1 1

A rollup tz release would be helpful
by Andy Heninger July 18, 2014

July 18, 2014

There have been a pretty substantial number of refactoring and cleanup changes to the experimental tz repository over the last month, and things now seem to be settling down. Speaking as the person who does a fair amount of the integration of tz releases into Google, I would definitely find it helpful to have an official release that includes these changes happen sooner rather than later. Past experience suggests that there may be a few internal glitches to be sorted through, and I would far prefer to handle them now, while not under pressure to get some low-lead-time rule change deployed in a hurry. We only deploy official tz releases, not informal repository snapshots. Thanks, -- Andy

3 2