- tz - lists.iana.org

Proposal to rename time.tab to region.tab
by Tobias Conradi July 23, 2014

July 23, 2014

Proposal to rename time.tab which was announced 2014-07-18 http://mm.icann.org/pipermail/tz/2014-July/021213.html to region.tab with reasoning as in Proposal to rename zone.tab to region.tab http://mm.icann.org/pipermail/tz/2014-July/021227.html But since time.tab is not yet publish with the additional benefit that there would be no file renaming for an end user. Reason: - it is a list of geographical regions - it is not a list of time ftp://ftp.iana.org/tz/code/Theory says ----- Scope of the tz database ----- ... To represent this data, the world is partitioned into regions .... For each such region, the database records all known clock transitions, and labels the region ...... Uniquely identify every national region .... Indicate to humans as to where that region is. .... is the name of a specific location within that region. ..... Uninhabited regions like ..... If all the clocks in a region have agreed since 1970, .... even if subregions' clocks disagreed before 1970. ...... Use cities or small islands, not countries or regions, [! other meaning] ..... The file `zone.tab' lists the geographical locations used to name time zone rule files. It is intended to be an exhaustive list of names for geographic regions as described above. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com

1 0

tzselect.ksh fails under ksh, works under bash
by Alan Barrett July 22, 2014

July 22, 2014

If BASH_VERSION is not set, then tzselect.ksh performs a test in which it attmepts to use the select command, to see whether the select command is available: 84: (eval 'set --; select x; do break; done; exit') 2>/dev/null In the case that the shell is not bash, but the select command is available, then the select command reads a line of input. This is confusing for users, who don't even see a prompt. The attached patch fixes this by redirecting input from /dev/null. I also quoted some variables on general principles. --apb (Alan Barrett)

2 1

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 19, 2014

July 19, 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 19, 2014

July 19, 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 19, 2014

July 19, 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 19, 2014

July 19, 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