May 2016 - tz - lists.iana.org

proposed time zone package changes (Samoa, Factory, et al.)
by Arthur David Olson Aug. 28, 2019

Aug. 28, 2019

Below find proposed time zone package changes; the executive summary: * Makefile Change LOCALTIME default from "Factory" to "GMT"; do not compile "factory" file (but keep it in the distribution). * Theory Remove reference to "Factory" zone. * australasia Change end of DST in Samoa in 2011 from 2011-04-03 0:00 to 2011-04-03 1:00 (thanks to Raymond Hughes for a reference). * localtime.c Initialize ttinfo structures filled by tzparse (thanks to Ravindra for reporting a valgrind warning). * zic.c Fix generation of POSIX strings for zones with rules using "weekday<=n" forms of dates (thanks to Lei Liu for finding the problem). Also, limit output for non-POSIX-specificable zones defined to follow the same rules every year. (Note that no zones of either of the above types appear in the distribution; these changes cater to add-on zones). If no problems are found, 2010n will appear on 2010-10-25. --ado diff -r -c old/Makefile new/Makefile *** old/Makefile Mon Sep 27 09:24:25 2010 --- new/Makefile Tue Oct 12 12:36:50 2010 *************** *** 1,5 **** # <pre> ! # @(#)Makefile 8.8 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)Makefile 8.9 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 12,18 **** # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= Factory # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, --- 12,18 ---- # make zonenames # to get a list of the values you can use for LOCALTIME. ! LOCALTIME= GMT # If you want something other than Eastern United States time as a template # for handling POSIX-style time zone environment variables, *************** *** 262,269 **** DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera factory backward ! NDATA= systemv SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab --- 262,269 ---- DOCS= README Theory $(MANS) date.1 Makefile PRIMARY_YDATA= africa antarctica asia australasia \ europe northamerica southamerica ! YDATA= $(PRIMARY_YDATA) pacificnew etcetera backward ! NDATA= systemv factory SDATA= solar87 solar88 solar89 TDATA= $(YDATA) $(NDATA) $(SDATA) TABDATA= iso3166.tab zone.tab diff -r -c old/Theory new/Theory *** old/Theory Mon Sep 27 09:24:25 2010 --- new/Theory Tue Oct 12 12:36:50 2010 *************** *** 1,4 **** ! @(#)Theory 8.4 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. --- 1,4 ---- ! @(#)Theory 8.5 This file is in the public domain, so clarified as of 2009-05-17 by Arthur David Olson. *************** *** 287,294 **** See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', `EET' (see the file `europe'), ! and `Factory' (see the file `factory'). ----- Time zone abbreviations ----- --- 287,293 ---- See the file `backward' for most of these older names (e.g. `US/Eastern' instead of `America/New_York'). The other old-fashioned names still supported are ! `WET', `CET', `MET', and `EET' (see the file `europe'). ----- Time zone abbreviations ----- diff -r -c old/australasia new/australasia *** old/australasia Mon Sep 27 09:24:27 2010 --- new/australasia Tue Oct 12 13:14:56 2010 *************** *** 1,5 **** # <pre> ! # @(#)australasia 8.18 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. --- 1,5 ---- # <pre> ! # @(#)australasia 8.19 # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. *************** *** 487,497 **** # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 -11:00 - WST # Solomon Is --- 487,507 ---- # http://www.parliament.gov.ws/documents/acts/Daylight%20Saving%20Act%20%2020… # </a> + # From Raymond Hughes (2010-10-07): + # Please see + # <a href="http://www.mcil.gov.ws"> + # http://www.mcil.gov.ws + # </a>, + # the Ministry of Commerce, Industry and Labour (sideframe) "Last Sunday + # September 2010 (26/09/10) - adjust clocks forward from 12:00 midnight + # to 01:00am and First Sunday April 2011 (03/04/11) - adjust clocks + # backwards from 1:00am to 12:00am" + Zone Pacific/Apia 12:33:04 - LMT 1879 Jul 5 -11:26:56 - LMT 1911 -11:30 - SAMT 1950 # Samoa Time -11:00 - WST 2010 Sep 26 ! -11:00 1:00 WSDT 2011 Apr 3 1:00 -11:00 - WST # Solomon Is diff -r -c old/localtime.c new/localtime.c *** old/localtime.c Mon Sep 27 09:24:26 2010 --- new/localtime.c Tue Oct 12 12:36:51 2010 *************** *** 5,11 **** #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.14"; #endif /* !defined NOID */ #endif /* !defined lint */ --- 5,11 ---- #ifndef lint #ifndef NOID ! static char elsieid[] = "@(#)localtime.c 8.15"; #endif /* !defined NOID */ #endif /* !defined lint */ *************** *** 914,919 **** --- 914,920 ---- register unsigned char * typep; register char * cp; register int load_result; + static struct ttinfo zttinfo; INITIALIZE(dstname); stdname = name; *************** *** 986,991 **** --- 987,993 ---- /* ** Two transitions per year, from EPOCH_YEAR forward. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -dstoffset; sp->ttis[0].tt_isdst = 1; sp->ttis[0].tt_abbrind = stdlen + 1; *************** *** 1099,1106 **** } /* ** Finally, fill in ttis. - ** ttisstd and ttisgmt need not be handled. */ sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; --- 1101,1108 ---- } /* ** Finally, fill in ttis. */ + sp->ttis[0] = sp->ttis[1] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = FALSE; sp->ttis[0].tt_abbrind = 0; *************** *** 1113,1118 **** --- 1115,1121 ---- dstlen = 0; sp->typecnt = 1; /* only standard time */ sp->timecnt = 0; + sp->ttis[0] = zttinfo; sp->ttis[0].tt_gmtoff = -stdoffset; sp->ttis[0].tt_isdst = 0; sp->ttis[0].tt_abbrind = 0; diff -r -c old/zic.c new/zic.c *** old/zic.c Mon Sep 27 09:24:26 2010 --- new/zic.c Tue Oct 12 13:37:29 2010 *************** *** 3,9 **** ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.22"; #include "private.h" #include "locale.h" --- 3,9 ---- ** 2006-07-17 by Arthur David Olson. */ ! static char elsieid[] = "@(#)zic.c 8.24"; #include "private.h" #include "locale.h" *************** *** 1881,1896 **** register int week; if (rp->r_dycode == DC_DOWGEQ) { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if ((week - 1) * DAYSPERWEEK + 1 != rp->r_dayofmonth) return -1; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! week = 1 + rp->r_dayofmonth / DAYSPERWEEK; ! if (week * DAYSPERWEEK - 1 != rp->r_dayofmonth) return -1; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", --- 1881,1896 ---- register int week; if (rp->r_dycode == DC_DOWGEQ) { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 1) return -1; + week = 1 + rp->r_dayofmonth / DAYSPERWEEK; } else if (rp->r_dycode == DC_DOWLEQ) { if (rp->r_dayofmonth == len_months[1][rp->r_month]) week = 5; else { ! if ((rp->r_dayofmonth % DAYSPERWEEK) != 0) return -1; + week = rp->r_dayofmonth / DAYSPERWEEK; } } else return -1; /* "cannot happen" */ (void) sprintf(result, "M%d.%d.%d", *************** *** 2018,2023 **** --- 2018,2024 ---- register char * envvar; register int max_abbr_len; register int max_envvar_len; + register int prodstic; /* all rules are min to max */ max_abbr_len = 2 + max_format_len + max_abbrvar_len; max_envvar_len = 2 * max_abbr_len + 5 * 9; *************** *** 2032,2037 **** --- 2033,2039 ---- timecnt = 0; typecnt = 0; charcnt = 0; + prodstic = zonecount == 1; /* ** Thanks to Earl Chew ** for noting the need to unconditionally initialize startttisstd. *************** *** 2053,2058 **** --- 2055,2062 ---- updateminmax(rp->r_loyear); if (rp->r_hiwasnum) updateminmax(rp->r_hiyear); + if (rp->r_lowasnum || rp->r_hiwasnum) + prodstic = FALSE; } } /* *************** *** 2075,2080 **** --- 2079,2094 ---- if (max_year <= INT_MAX - YEARSPERREPEAT) max_year += YEARSPERREPEAT; else max_year = INT_MAX; + /* + ** Regardless of any of the above, + ** for a "proDSTic" zone which specifies that its rules + ** always have and always will be in effect, + ** we only need one cycle to define the zone. + */ + if (prodstic) { + min_year = 1900; + max_year = min_year + YEARSPERREPEAT; + } } /* ** For the benefit of older systems,

5 6

Syntax highlighting for Sublime Text
by Gilmore Davidson Aug. 16, 2017

Aug. 16, 2017

Hi, I’ve created some tzdata syntax highlighting rules for the Sublime Text editor: https://packagecontrol.io/packages/zoneinfo <https://packagecontrol.io/packages/zoneinfo> I have no idea if anyone other than me uses that particular text editor for looking at tzdata files. But I thought I’d mention it just in case it’s useful to someone. Cheers, Gil

3 3

Re: [tz] Version in zoneinfo files?
by Guy Harris Feb. 10, 2017

Feb. 10, 2017

On Oct 25, 2015, at 10:55 AM, Paul G <paul(a)ganssle.io> wrote: > I'm not suggesting that it be impossible to create a weird result when asking for the version, just that there's a standard place for the version to go, and preferably the standard default gives you something that you expected. I.e., something that works most of the time is sufficient? So what exactly is the intended use of this version field? > As it is now, you're virtually guaranteed to have a lot of incompatibility because there's nothing you can point to that says, "This is the canonical way to store version information about zoneinfo files", and no standard has emerged on how to do this as is. > > On 10/25/2015 01:51 PM, Guy Harris wrote: >> >> On Oct 25, 2015, at 10:37 AM, Paul G <paul(a)ganssle.io> wrote: >> >>> On 10/25/2015 01:35 PM, Guy Harris wrote: >>> >>>> So where would zic get the version information to put into the binary files? >>> >>> My understanding is that it's the VERSION= line of the Makefile in the tzdata tarballs. >> >> I.e., you're proposing that the value of the VERSION value in the Makefile be passed as an argument to zic, and zic would put the value of that argument into a field in the files? >> >> So, if the goal is to provide a "reliable way to get the version information in a cross-platform way", what would ensure that this field be set properly, for some value of "properly", everywhere that binary tzdata files are generated? >> >> I.e., what is to guarantee that >> >> 1) nobody downstream change VERSION if they aren't changing the zic files from what's distributed >> >> and >> >> 2) people change it "properly" if the files don't correspond to a particular version of files that were distributed (e.g., if some downstream supplier takes 2015q and adds some changes mentioned on the list to it before 2015r comes out with those changes plus other changes, they should call the resulting files something other than "2015q" or "2015r")? >> >

20 55

Proposal: validation text file with releases
by Jon Skeet Dec. 19, 2016

Dec. 19, 2016

Background: I'm the primary developer for Noda Time <http://nodatime.org> which consumes the tz data. I'm currently refactoring the code to do this... and I've come across some code (originally ported from Joda Time) which I now understand in terms of what it's doing, but not exactly why. For a little while now, the Noda Time source repo has included a text dump file <https://github.com/nodatime/nodatime/blob/master/src/NodaTime.Test/TestData…>, containing a text dump of every transition (up to 2100, at the moment) for every time zone. It looks like this, picking just one example: Zone: Africa/Maseru LMT: [StartOfTime, 1892-02-07T22:08:00Z) +01:52 (+00) SAST: [1892-02-07T22:08:00Z, 1903-02-28T22:30:00Z) +01:30 (+00) SAST: [1903-02-28T22:30:00Z, 1942-09-20T00:00:00Z) +02 (+00) SAST: [1942-09-20T00:00:00Z, 1943-03-20T23:00:00Z) +03 (+01) SAST: [1943-03-20T23:00:00Z, 1943-09-19T00:00:00Z) +02 (+00) SAST: [1943-09-19T00:00:00Z, 1944-03-18T23:00:00Z) +03 (+01) SAST: [1944-03-18T23:00:00Z, EndOfTime) +02 (+00) I use this file for confidence when refactoring my time zone handling code - if the new code comes up with the same set of transitions as the old code, it's probably okay. (This is just one line of defence, of course - there are unit tests, though not as many as I'd like.) It strikes me that having a similar file (I'm not wedded to the format, but it should have all the same information, one way or another) released alongside the main data files would be really handy for *all* implementors - it would be a good way of validating consistency across multiple platforms, with the release data being canonical. For any platforms which didn't want to actually consume the rules as rules, but just wanted a list of transitions, it could even effectively replace their use of the data. One other benefit: diffing the dump between two releases would make it clear what had changed in *effect*, rather than just in terms of rules. One sticking point is size. The current file for Noda Time is about 4MB, although it zips down to about 300K. Some thoughts around this: - We wouldn't need to distribute it in the same file as the data - just as we have data and code file, there could be a "textdump" file or whatever we'd want to call it. These could be retroactively generated for previous releases, too. - As you can see, there's redundancy in the format above, in that it's a list of "zone intervals" (as I call them in Noda Time) rather than a list of transitions - the end of each interval is always the start of the next interval. - For zones which settle into an infinite daylight saving pattern, I currently generate from the start of time to 2100 (and then a single zone interval for the end of time as Noda Time understands it; we'd need to work out what form that would take, if any). If we decided that "year of release + 30 years" was enough, that would cut down the size considerably. Any thoughts? If the feeling is broadly positive, the next step would be to nail down the text format, then find a willing victim/volunteer to write the C code. (You really don't want me writing C...) Jon

18 92

Blog Post: On the Timing of Time Zone Changes
by Matt Johnson July 26, 2016

July 26, 2016

I've written a blog post describing the chaos that ensues when governments don't provide enough notice of their changes to time zones. http://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/ <http://aka.ms/weboutlook> Enjoy! -Matt

11 15

Saratov and Novosibirsk proposed to change their time zones
by Stepan Golosunov July 4, 2016

July 4, 2016

Hi, Search for "об исчислении времени" on http://asozd2.duma.gov.ru/main.nsf/SearchUD?OpenForm revealed 3 new bills changing time zone borders in Russia: http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1058438-6 and http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1083558-6 move Saratov oblast from UTC+3 to UTC+4. http://asozd2.duma.gov.ru/main.nsf/(Spravka)?OpenAgent&RN=1085784-6 moves Novosibirsk oblast from UTC+6 to UTC+7. Given that the last two bills are proposed by regional parliaments, they are likely to be approved. When is less clear. The bills currently have effective dates in July, but that can be easily changed before the second readings. And they are just received while there are only 4 weeks before the summer break in the State Duma.

2 4

Egypt to have DST again
by Steffen Thorsen July 2, 2016

July 2, 2016

Several of our users have reported on new DST plans in Egypt, which is confirmed by several sources that all say Egypt will have DST from July 7 until the end of October. Unfortunately, "end of October" is very vague, but we at timeanddate.com would assume a rule like this for it, based on their historic end dates: Rule Egypt 2016 max - Oct lastThu 23:00s 0 - We also assume it will start at the end of July 7 (midnight between Thursday and Friday). http://english.ahram.org.eg/NewsContentP/1/204655/Egypt/Daylight-savings-ti… http://www.nileinternational.net/en/?p=25806 I found it interesting that EgyptAir seems to have assumed DST to start in April (like it previously did in 2010), and therefore this obviously causes problems with the schedules: http://www.egyptair.com/en/about-egyptair/news-and-press/Pages/CANCELLATION… Best regards, Steffen Thorsen - timeanddate.com

16 31

Asia/Tomsk
by Victor Sudakov June 7, 2016

June 7, 2016

Dear Colleagues, As a citizen of Tomsk, I would like to raise some questions concerning the recent addition of the Asia/Tomsk timezone. As you know, this time zone's abbreviation is all numeric: Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - +06 1930 Jun 21 7:00 Russia +07/+08 1991 Mar 31 2:00s 6:00 Russia +06/+07 1992 Jan 19 2:00s 7:00 Russia +07/+08 2002 May 1 3:00 6:00 Russia +06/+07 2011 Mar 27 2:00s 7:00 - +07 2014 Oct 26 2:00s 6:00 - +06 2016 May 29 2:00s 7:00 - +07 In my opinion, it is bad for two reasons: 1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)' 2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name! Could we do something about Asia/Tomsk and other zones with share the same fate: Europe/Astrakhan, Europe/Kirov, Europe/Ulyanovsk, Asia/Barnaul? Thank you for your attention. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

14 57

Re: [tz] YouTube videos on time zones
by Steve Jones May 30, 2016

May 30, 2016

At 01:14 PM 3/8/2016, Matt Johnson wrote: >If these two aren't in our art file, they probably should be. One mustn't forget the trailer for "Daylight Saving", the movie: https://www.youtube.com/watch?v=k4EUTMPuvHo Regards, Steve Jones

3 2

New time zone library
by Matt Johnson May 30, 2016

May 30, 2016

Please add to the tz-link file under Other tz compilers: Lau's Tzdata library for the Elixir language automatically downloads and compiles tz source data, and exposes APIs for use. It is freely available under the MIT license. https://github.com/lau/tzdata Thanks, Matt

2 1

[PROPOSED PATCH] * zic.c: Update comments for Qt and GNOME bugs.
by Paul Eggert May 30, 2016

May 30, 2016

--- zic.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/zic.c b/zic.c index 2284d2c..3eb65d3 100644 --- a/zic.c +++ b/zic.c @@ -143,11 +143,11 @@ static bool yearistype(int year, const char * type); /* Bound on length of what %z can expand to. */ enum { PERCENT_Z_LEN_BOUND = sizeof "+995959" - 1 }; -/* If true, work around a bug in Qt 5.6 and earlier, which mishandles +/* If true, work around a bug in Qt 5.6.1 and earlier, which mishandles tzdata binary files whose POSIX-TZ-style strings contain '<'; see QTBUG-53071 <https://bugreports.qt.io/browse/QTBUG-53071>. This - workaround will no longer be needed when Qt 5.6 is obsolete, say in - the year 2021. */ + workaround will no longer be needed when Qt 5.6.1 and earlier are + obsolete, say in the year 2021. */ enum { WORK_AROUND_QTBUG_53071 = true }; static int charcnt; @@ -880,7 +880,11 @@ static zic_t const max_time = MAXVAL (zic_t, TIME_T_BITS_IN_FILE); /* If true, work around GNOME bug 730332 <https://bugzilla.gnome.org/show_bug.cgi?id=730332> by refusing to output time stamps before BIG_BANG. - Such time stamps are physically suspect anyway. */ + Such time stamps are physically suspect anyway. + + The GNOME bug is scheduled to be fixed in GNOME 3.22, and if so + this workaround will no longer be needed when GNOME 3.21 and + earlier are obsolete, say in the year 2021. */ enum { WORK_AROUND_GNOME_BUG_730332 = true }; static const zic_t early_time = (WORK_AROUND_GNOME_BUG_730332 -- 2.5.5

1 0

[PROPOSED PATCH] Switch from 'zzz' to '-00' for uninhabited abbr
by Paul Eggert May 29, 2016

May 29, 2016

* NEWS, Theory, tz-how-to.html: Document this. * antarctica (Antarctica/Casey, Antarctica/Davis) (Antarctica/Mawson, Indian/Kerguelen, Antarctica/DumontDUrville): (Antarctica/Syowa, Antarctica/Troll, Antarctica/Vostok) (Antarctica/Rothera): * australasia (Antarctica/Macquarie): * backzone (Antarctica/McMurdo): * northamerica (America/Pangnirtung, America/Iqaluit) (America/Resolute, America/Rankin_Inlet, America/Cambridge_Bay) (America/Yellowknife, America/Inuvik): * southamerica (Antarctica/Palmer): Use '-00', not 'zzz', to abbreviate UT in uninhabited locations. --- NEWS | 7 +++++++ Theory | 7 ++++--- antarctica | 24 ++++++++++++------------ australasia | 4 ++-- backzone | 2 +- northamerica | 14 +++++++------- southamerica | 2 +- tz-how-to.html | 16 ++++++++++------ 8 files changed, 44 insertions(+), 32 deletions(-) diff --git a/NEWS b/NEWS index b5fb182..54a520d 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,13 @@ Unreleased, experimental changes Changes affecting past time stamps + Locations while uninhabited now use '-00', not 'zzz', as a + placeholder time zone abbreviation. This is inspired by Internet + RFC 3339 and is more consistent with numeric time zone + abbreviations already used elsewhere. The change affects several + arctic and antarctic locations, e.g., America/Cambridge_Bay before + 1920 and Antarctica/Troll before 2005. + Asia/Baku's 1992-09-27 transition from +04 (DST) to +04 (non-DST) was at 03:00, not 23:00 the previous day. (Thanks to Michael Deckers.) diff --git a/Theory b/Theory index 6bed91f..60678fe 100644 --- a/Theory +++ b/Theory @@ -227,9 +227,10 @@ in decreasing order of importance: name identifying each zone and append 'T', 'ST', etc. as before; e.g. 'VLAST' for VLAdivostok Summer Time. - Use UT (with time zone abbreviation 'zzz') for locations while - uninhabited. The 'zzz' mnemonic is that these locations are, - in some sense, asleep. + Use UT (with time zone abbreviation '-00') for locations while + uninhabited. The leading '-' is a flag that the time + zone is in some sense undefined; this notation is + derived from Internet RFC 3339. Application writers should note that these abbreviations are ambiguous in practice: e.g. 'CST' has a different meaning in China than diff --git a/antarctica b/antarctica index 2af088f..a537832 100644 --- a/antarctica +++ b/antarctica @@ -13,7 +13,7 @@ # # Except for the French entries, # I made up all time zone abbreviations mentioned here; corrections welcome! -# FORMAT is 'zzz' and GMTOFF is 0 for locations while uninhabited. +# FORMAT is '-00' and GMTOFF is 0 for locations while uninhabited. # Argentina - year-round bases # Belgrano II, Confin Coast, -770227-0343737, since 1972-02-05 @@ -67,22 +67,22 @@ # http://www.timeanddate.com/news/time/antartica-time-changes-2010.html # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/Casey 0 - zzz 1969 +Zone Antarctica/Casey 0 - -00 1969 8:00 - AWST 2009 Oct 18 2:00 # Australian Western Std Time 11:00 - CAST 2010 Mar 5 2:00 # Casey Time 8:00 - AWST 2011 Oct 28 2:00 11:00 - CAST 2012 Feb 21 17:00u 8:00 - AWST -Zone Antarctica/Davis 0 - zzz 1957 Jan 13 +Zone Antarctica/Davis 0 - -00 1957 Jan 13 7:00 - DAVT 1964 Nov # Davis Time - 0 - zzz 1969 Feb + 0 - -00 1969 Feb 7:00 - DAVT 2009 Oct 18 2:00 5:00 - DAVT 2010 Mar 10 20:00u 7:00 - DAVT 2011 Oct 28 2:00 5:00 - DAVT 2012 Feb 21 20:00u 7:00 - DAVT -Zone Antarctica/Mawson 0 - zzz 1954 Feb 13 +Zone Antarctica/Mawson 0 - -00 1954 Feb 13 6:00 - MAWT 2009 Oct 18 2:00 # Mawson Time 5:00 - MAWT # References: @@ -137,7 +137,7 @@ Zone Antarctica/Mawson 0 - zzz 1954 Feb 13 # fishing stations operated variously 1819/1931 # # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Indian/Kerguelen 0 - zzz 1950 # Port-aux-Français +Zone Indian/Kerguelen 0 - -00 1950 # Port-aux-Français 5:00 - TFT # ISO code TF Time # # year-round base in the main continent @@ -148,9 +148,9 @@ Zone Indian/Kerguelen 0 - zzz 1950 # Port-aux-Français # It was destroyed by fire on 1952-01-14. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/DumontDUrville 0 - zzz 1947 +Zone Antarctica/DumontDUrville 0 - -00 1947 10:00 - PMT 1952 Jan 14 # Port-Martin Time - 0 - zzz 1956 Nov + 0 - -00 1956 Nov 10:00 - DDUT # Dumont-d'Urville Time # France & Italy - year-round base @@ -176,7 +176,7 @@ Zone Antarctica/DumontDUrville 0 - zzz 1947 # was established on 1957-01-29. Since Syowa station is still the main # station of Japan, it's appropriate for the principal location. # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/Syowa 0 - zzz 1957 Jan 29 +Zone Antarctica/Syowa 0 - -00 1957 Jan 29 3:00 - SYOT # Syowa Time # See: # NIPR Antarctic Research Activities (1999-08-17) @@ -226,7 +226,7 @@ Rule Troll 2005 max - Mar lastSun 1:00u 2:00 CEST # Remove the following line when uncommenting the above '#Rule' lines. Rule Troll 2004 max - Oct lastSun 1:00u 0:00 UTC # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/Troll 0 - zzz 2005 Feb 12 +Zone Antarctica/Troll 0 - -00 2005 Feb 12 0:00 Troll %s # Poland - year-round base @@ -267,7 +267,7 @@ Zone Antarctica/Troll 0 - zzz 2005 Feb 12 # happened to be during their visit. So we still don't really know what time # it is at Vostok. But we'll guess UTC+6. # -Zone Antarctica/Vostok 0 - zzz 1957 Dec 16 +Zone Antarctica/Vostok 0 - -00 1957 Dec 16 6:00 - VOST # Vostok time # S Africa - year-round bases @@ -300,7 +300,7 @@ Zone Antarctica/Vostok 0 - zzz 1957 Dec 16 # <http://webexhibits.org/daylightsaving/g.html> says Rothera is -03 all year. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/Rothera 0 - zzz 1976 Dec 1 +Zone Antarctica/Rothera 0 - -00 1976 Dec 1 -3:00 - ROTT # Rothera time # Uruguay - year round base diff --git a/australasia b/australasia index 55f44cf..0b33f67 100644 --- a/australasia +++ b/australasia @@ -243,11 +243,11 @@ Zone Australia/Lord_Howe 10:36:20 - LMT 1895 Feb # will produce a binary file with an [A]EST-type as the first 32-bit type; # this is required for correct handling of times before 1916 by # pre-2013 versions of localtime. -Zone Antarctica/Macquarie 0 - zzz 1899 Nov +Zone Antarctica/Macquarie 0 - -00 1899 Nov 10:00 - AEST 1916 Oct 1 2:00 10:00 1:00 AEDT 1917 Feb 10:00 Aus AE%sT 1919 Apr 1 0:00s - 0 - zzz 1948 Mar 25 + 0 - -00 1948 Mar 25 10:00 Aus AE%sT 1967 10:00 AT AE%sT 2010 Apr 4 3:00 11:00 - MIST # Macquarie I Standard Time diff --git a/backzone b/backzone index 296eca8..13dc8d4 100644 --- a/backzone +++ b/backzone @@ -395,7 +395,7 @@ Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town -4:00 - AST # McMurdo, Ross Island, since 1955-12 -Zone Antarctica/McMurdo 0 - zzz 1956 +Zone Antarctica/McMurdo 0 - -00 1956 12:00 NZ NZ%sT Link Antarctica/McMurdo Antarctica/South_Pole diff --git a/northamerica b/northamerica index 1d7395c..6256f97 100644 --- a/northamerica +++ b/northamerica @@ -2191,39 +2191,39 @@ Rule NT_YK 1980 2006 - Oct lastSun 2:00 0 S Rule NT_YK 1987 2006 - Apr Sun>=1 2:00 1:00 D # Zone NAME GMTOFF RULES FORMAT [UNTIL] # aka Panniqtuuq -Zone America/Pangnirtung 0 - zzz 1921 # trading post est. +Zone America/Pangnirtung 0 - -00 1921 # trading post est. -4:00 NT_YK A%sT 1995 Apr Sun>=1 2:00 -5:00 Canada E%sT 1999 Oct 31 2:00 -6:00 Canada C%sT 2000 Oct 29 2:00 -5:00 Canada E%sT # formerly Frobisher Bay -Zone America/Iqaluit 0 - zzz 1942 Aug # Frobisher Bay est. +Zone America/Iqaluit 0 - -00 1942 Aug # Frobisher Bay est. -5:00 NT_YK E%sT 1999 Oct 31 2:00 -6:00 Canada C%sT 2000 Oct 29 2:00 -5:00 Canada E%sT # aka Qausuittuq -Zone America/Resolute 0 - zzz 1947 Aug 31 # Resolute founded +Zone America/Resolute 0 - -00 1947 Aug 31 # Resolute founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 -5:00 - EST 2001 Apr 1 3:00 -6:00 Canada C%sT 2006 Oct 29 2:00 -5:00 - EST 2007 Mar 11 3:00 -6:00 Canada C%sT # aka Kangiqiniq -Zone America/Rankin_Inlet 0 - zzz 1957 # Rankin Inlet founded +Zone America/Rankin_Inlet 0 - -00 1957 # Rankin Inlet founded -6:00 NT_YK C%sT 2000 Oct 29 2:00 -5:00 - EST 2001 Apr 1 3:00 -6:00 Canada C%sT # aka Iqaluktuuttiaq -Zone America/Cambridge_Bay 0 - zzz 1920 # trading post est.? +Zone America/Cambridge_Bay 0 - -00 1920 # trading post est.? -7:00 NT_YK M%sT 1999 Oct 31 2:00 -6:00 Canada C%sT 2000 Oct 29 2:00 -5:00 - EST 2000 Nov 5 0:00 -6:00 - CST 2001 Apr 1 3:00 -7:00 Canada M%sT -Zone America/Yellowknife 0 - zzz 1935 # Yellowknife founded? +Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? -7:00 NT_YK M%sT 1980 -7:00 Canada M%sT -Zone America/Inuvik 0 - zzz 1953 # Inuvik founded +Zone America/Inuvik 0 - -00 1953 # Inuvik founded -8:00 NT_YK P%sT 1979 Apr lastSun 2:00 -7:00 NT_YK M%sT 1980 -7:00 Canada M%sT diff --git a/southamerica b/southamerica index fb437b2..1c38f63 100644 --- a/southamerica +++ b/southamerica @@ -1309,7 +1309,7 @@ Zone Pacific/Easter -7:17:28 - LMT 1890 # Palmer used to be supplied from Argentina. # # Zone NAME GMTOFF RULES FORMAT [UNTIL] -Zone Antarctica/Palmer 0 - zzz 1965 +Zone Antarctica/Palmer 0 - -00 1965 -4:00 Arg AR%sT 1969 Oct 5 -3:00 Arg AR%sT 1982 May -4:00 Chile CL%sT diff --git a/tz-how-to.html b/tz-how-to.html index 3fa7602..f0fedc5 100644 --- a/tz-how-to.html +++ b/tz-how-to.html @@ -466,13 +466,11 @@ offset, so the wall clock time during this period was GMT − 10:30 + 1:00 = GMT − 9:30. The <code>FORMAT</code> column specifies the usual abbreviation of -the time zone name. It can have one of four forms: +the time zone name. It can have one of three forms: <ul> -<li>the string, “<code>zzz</code>,” which is a kind of -null value (don’t ask)</li> - -<li>a single alphabetic string other than “<code>zzz</code>,” +<li>a string of three or more characters that are either ASCII alphanumerics, +“<code>+</code>”, or “<code>-</code>”, in which case that’s the abbreviation</li> <li>a pair of strings separated by a slash @@ -513,7 +511,7 @@ a <code>SAVE</code> of zero. </ul> -And two last things about the <code>FORMAT</code> column: +And three last things about the <code>FORMAT</code> column: <ul> <li>The <a href="https://en.wikipedia.org/wiki/Tz_database">tz @@ -535,6 +533,12 @@ the abbreviations. They are intended to be the values returned through the <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html"><code>strftime</code></a> function in the <a href="http://www.chemie.fu-berlin.de/chemnet/use/info/libc/libc_19.html#SEC324">“C” locale</a>. + +<li>If there is no generally-accepted abbreviation for a time zone, +a numeric offset is used instead, e.g., <code>+07</code> for 7 hours +ahead of Greenwich. By convention, <code>-00</code> stands for an +zone while uninhabited, where the offset is zero but in some sense +the true offset is undefined. </ul> As a final example, here’s the complete history for Hawaii: -- 2.5.5

1 0

[PROPOSED PATCH] Fix "-"s in zic man page with Bell Labs troff
by Paul Eggert May 29, 2016

May 29, 2016

* zic.8: Fix a typo in defining \*- when using traditional troff. --- zic.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.8 b/zic.8 index 94b6753..e5e71f5 100644 --- a/zic.8 +++ b/zic.8 @@ -26,7 +26,7 @@ zic \- time zone compiler .\} .el \{\ . ds : -. el ds - \- +. ds - \- .\} .I Zic reads text from the file(s) named on the command line -- 2.5.5

1 0

efele.net/tz maps updated for 2016d
by Eric Muller May 28, 2016

May 28, 2016

1 0

Morocco rule to suspend DST for RAMADAN
by BENNANI RHITA May 28, 2016

May 28, 2016

Hi, We are facing again a small change on the period for which Morocco will suspend DST. The rule actually applied on our system is : Morocco will temporarily switch to standard time at 03:00 the last Saturday before Ramadan, and back to DST at 02:00 the first Saturday after Ramadan. While in fact and according to the latest official decree the temporary DST suspension is as below : Morocco will temporarily switch to standard time at 03:00 the last Sunday before Ramadan, and back to DST at 02:00 the first Sunday after Ramadan. So Morocco will suspend DST from 2016-06-05 03:00 through 2016-07-10 02:00, not 06-04 and 07-09 as guessed. Is there a way to update the TZupdater in order to correct this. We really need to update it before 1st of June in order to publish our schedules correctly for the days 06-04 and 07-10. Thanks a lot, Best regards [Description : cid:image001.png@01D010AD.0526CD40] BENNANI Rhita Chef de Projet Département Commercial et Exploitation Direction Organisation et Systèmes d'Information +212 522 91 22 36 www.royalairmaroc.com<http://www.royalairmaroc.com/> [Description : cid:image001.jpg@01D01561.B1BD0430] <http://www.facebook.com/RoyalAirMaroc> [Description : cid:image002.jpg@01D01561.B1BD0430] <https://twitter.com/RAM_Maroc> [Description : cid:image003.jpg@01D01561.B1BD0430] <https://plus.google.com/116698608481885525601> [Description : Description : cid:image005.png@01D00B0B.40B7FD90]

3 3

Anecdotal discrepancy for Navajo nation in Arizona
by Deborah Goldsmith May 27, 2016

May 27, 2016

Hi, A colleague recently visited Page, Arizona, and the Navajo reservation right next to it. His phone must have been associated with a cell tower inside the Navajo nation, because his zone was set by NITZ to America/Denver (DST in effect). This matches the current TZ database. However, he observed that the parts of the Navajo nation adjacent to Page were actually observing the same time zone as Page (America/Phoenix, DST not in effect). I wouldn’t make any changes based on this one anecdote, but it might be worth checking if anyone has any sources inside the Navajo nation. Thanks, Debbie

8 12

Re: [tz] Asia/Tomsk
by vanadovv＠hetnet.nl May 26, 2016

May 26, 2016

>----Origineel Bericht---- >Van : guy(a)alum.mit.edu >Datum : 26/05/2016 11:08 >Aan : vas(a)mpeks.tomsk.su >Cc : tz(a)iana.org >Onderwerp : Re: [tz] Asia/Tomsk > >On May 25, 2016, at 10:19 AM, Victor Sudakov <vas(a)mpeks.tomsk.su> wrote: > >> As a member of the public, I don't like the idea of the tz project >> calling my time zone <+07> :-) > >As a member of the tzdb project (albeit one whose main effort was ages ago), I don't like the idea of expecting people not necessarily from the locale of a tzdb zone to pick abbreviations for times in the zone and then deal with complaints from people from that locale. :-) > My reply: Look at the law: the official time zone name for Tomsk is: 6-я часовая зона (If utf-8 is working, then you'll see Russian in Cyrillic letters.) The English translation is: 6th hourly zone (6th timezone). Cheerio! Oscar van Vlijmen

4 5

Ireland Summer Time History
by Matt Johnson May 25, 2016

May 25, 2016

Interesting article with historical details of Ireland's adoption of DST: http://www.rte.ie/centuryireland/index.php/articles/here-comes-the-summer-d…

1 0

Re: [tz] Anecdotal discrepancy for Navajo nation in Arizona
by Steve Jones May 25, 2016

May 25, 2016

At 10:53 PM 5/24/2016, Brian Inglis wrote: >Federal facilities and areas within AZ are subject to federal >legislation so they too observe DST. Federal legislation deals with time zone borders, not DST observance. DST observance is a state (and Indian) matter. Only AZ and HI have decided not to observe. Federal facilities located in those states therefore do not observe DST. Everything from national parks to post offices to federal polling places. Indian nations are deemed to have similar authority - and that it supersedes that of the state in which they are located. So on reservation lands the Navajo decision to observe DST trumps the AZ decision not to. Federal facilities inside the Navajo reservation observe time per the Navajo authority instead of the AZ authority. There are also exceptions to federal facilities deviating from official local time. The only one I knew of before today was Guadalupe Mountains National Park, which observes Mountain time despite being mostly located in the Central time zone. Today I learned of the Dangling Rope Marina exception. Regards, Steve Jones Emacs!

2 1

Re: [tz] Anecdotal discrepancy for Navajo nation in Arizona
by Sterling Udell May 25, 2016

May 25, 2016

> Federal facilities and areas within AZ are subject to federal > legislation so they too observe DST. That's not correct. I'm currently at Pipe Spring National Monument (a federal facility in AZ), and despite being just a few miles from the Utah border, it follows the bulk of AZ in *not* observing DST. I can tell you the same is true for Grand Canyon National Park, Petrified Forest NP, Organ Pipe Cactus NP, and other NPS locations here. On the other hand, Hubbell Trading Post National Historic Site - which is surrounded by the Navajo reservation - follows the Navajo in observing DST. In general, NPS sites in Arizona observe the time of their surrounding areas. I would strongly expect that the same is true for other federal facilities in Phoenix, Tucson, or wherever - it would just be too disruptive for the time zone to be different in a single building.

1 0

Re: [tz] Anecdotal discrepancy for Navajo nation in Arizona
by Steve Jones May 25, 2016

May 25, 2016

At 05:55 PM 5/24/2016, Arthur David Olson wrote: > > ...it might be worth checking if anyone has any sources inside > the Navajo nation. > >The source used back in 1987 (using--ahem--snail mail) was the Inter >Tribal Council of Arizona: <http://itcaonline.com/>http://itcaonline.com/. A very complex area: From http://ontimezone.com/exceptions.php: Even though Arizona does not observe Daylight Saving Time, the Navajo Indian Reservation (which takes up most of northeastern AZ) does observe DST. To add to the confusion, the Hopi Indian Reservation, which is wholly enclosed within the Navajo Reservation, does NOT observe DST. Confused? We're just getting started. * Consider also that the Navajos have an enclave containing the village of Jeddito, entirely within the Hopi reservation. And that the Hopi reservation has an exclave at Moenkopi, just south of Tuba City. Still not confused? * Some of the businesses in Tuba city (within the Navajo Reservation) reportedly do not observe Daylight Saving time, so as to avoid confusing the tourists. Good luck with that. At least that puts them in sync with their Hopi neighbors across highway 160 in Moenkopi. Got it? http://ontimezone.com/images/az_tribal.php Emacs! Steve Jones Emacs!

2 1

Re: [tz] tz Digest, Vol 56, Issue 13
by Uri Ramirez May 23, 2016

May 23, 2016

Help On May 23, 2016 5:00 AM, <tz-request(a)iana.org> wrote: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. Re: Morocco confirms Ramadan DST dates (Milamber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 22 May 2016 17:18:17 +0200 > From: Milamber <milamberspace(a)gmail.com> > To: Matt Johnson <mj1856(a)hotmail.com>, Time Zone Mailing List > <tz(a)iana.org> > Subject: Re: [tz] Morocco confirms Ramadan DST dates > Message-ID: <5741CDB9.9040900(a)gmail.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > Yes you are probably right, the arabic version seems have the good hour > (2:00 am) to the change. > Thanks. > > On 22/05/2016 04:54, Matt Johnson wrote: > > Thanks, but this appears to be a translation error. The Arabic version > on the same site says 2:00 instead of 3:00. See > http://mmsp.gov.ma/ar/actualites.aspx?id=1057 > > > > Given the history from previous years, I'm inclined to believe the > Arabic version. > > > > -Matt > > ________________________________________ > > From: Milamber <milamberspace(a)gmail.com> > > Sent: Saturday, May 21, 2016 3:24 PM > > To: Matt Johnson > > Subject: Re: [tz] Morocco confirms Ramadan DST dates > > > > Hello, > > > > The official link from the Ministry of Public service and Administration > > Modernization (in French): > > > > http://mmsp.gov.ma/fr/actualites.aspx?id=1056 > > > > Google Translation: > > "Back to the standard time of the Kingdom (GMT). > > The Ministry of Public Service and Modernization of Administration > > announces the return to standard time of the Kingdom (GMT). So time will > > be delayed for 60 minutes from 3:00 am Sunday, June 5, 2016. She will be > > advanced by 60 minutes (GMT + 1) from 3:00 am Sunday, July 10, 2016." > > > > > > One question: > > > > "She will be advanced by 60 minutes (GMT + 1) from 3:00 am Sunday, July > > 10, 2016." > > > > meaning this on zdump (current tzdata)? > > > > Africa/Casablanca Sun Jul 10 01:59:59 2016 UT = Sun Jul 10 01:59:59 > > 2016 WET isdst=0 gmtoff=0 > > Africa/Casablanca Sun Jul 10 02:00:00 2016 UT = Sun Jul 10 03:00:00 > > 2016 WEST isdst=1 gmtoff=3600 > > > > At 02am go to 03am or at 03am go to 04am? > > > > Milamber > > > > > > On 19/05/2016 06:30, Matt Johnson wrote: > >> > http://www.moroccoworldnews.com/2016/05/186863/morocco-goes-back-to-gmt-tim… > >> > >> Our guesses appear to be validated. > >> > > > > > > ------------------------------ > > _______________________________________________ > tz mailing list > tz(a)iana.org > https://mm.icann.org/mailman/listinfo/tz > > > End of tz Digest, Vol 56, Issue 13 > ********************************** >

1 0

Re: [tz] Morocco confirms Ramadan DST dates
by Milamber May 22, 2016

May 22, 2016

Yes you are probably right, the arabic version seems have the good hour (2:00 am) to the change. Thanks. On 22/05/2016 04:54, Matt Johnson wrote: > Thanks, but this appears to be a translation error. The Arabic version on the same site says 2:00 instead of 3:00. See http://mmsp.gov.ma/ar/actualites.aspx?id=1057 > > Given the history from previous years, I'm inclined to believe the Arabic version. > > -Matt > ________________________________________ > From: Milamber <milamberspace(a)gmail.com> > Sent: Saturday, May 21, 2016 3:24 PM > To: Matt Johnson > Subject: Re: [tz] Morocco confirms Ramadan DST dates > > Hello, > > The official link from the Ministry of Public service and Administration > Modernization (in French): > > http://mmsp.gov.ma/fr/actualites.aspx?id=1056 > > Google Translation: > "Back to the standard time of the Kingdom (GMT). > The Ministry of Public Service and Modernization of Administration > announces the return to standard time of the Kingdom (GMT). So time will > be delayed for 60 minutes from 3:00 am Sunday, June 5, 2016. She will be > advanced by 60 minutes (GMT + 1) from 3:00 am Sunday, July 10, 2016." > > > One question: > > "She will be advanced by 60 minutes (GMT + 1) from 3:00 am Sunday, July > 10, 2016." > > meaning this on zdump (current tzdata)? > > Africa/Casablanca Sun Jul 10 01:59:59 2016 UT = Sun Jul 10 01:59:59 > 2016 WET isdst=0 gmtoff=0 > Africa/Casablanca Sun Jul 10 02:00:00 2016 UT = Sun Jul 10 03:00:00 > 2016 WEST isdst=1 gmtoff=3600 > > At 02am go to 03am or at 03am go to 04am? > > Milamber > > > On 19/05/2016 06:30, Matt Johnson wrote: >> http://www.moroccoworldnews.com/2016/05/186863/morocco-goes-back-to-gmt-tim… >> >> Our guesses appear to be validated. >> >

1 0

Morocco confirms Ramadan DST dates
by Matt Johnson May 19, 2016

May 19, 2016

http://www.moroccoworldnews.com/2016/05/186863/morocco-goes-back-to-gmt-tim… Our guesses appear to be validated.

1 0

Getting offset for each time zones
by kailash kumar May 19, 2016

May 19, 2016

Hi All, I wanted to get UTC offset for each time zone which is present under zoneinfo folder. basically I wanted to create a drop down for all timezones with UTC offset, where user can select timezone. Please let me know if it is possible to get UTC offset for all time zones in tz database. Thanks, KAILASH KUMAR JAIN Legal Warning: This message may contain privileged and confidential information. If you are not the intended recipient or for any reason think that this message may have been address to you or reached you as a mistake, its requested that you must not disseminate,copy or take any action in reliance on it and I ask you to delete all copies from your mail box and computer system and also notify me immediately by return e-mail.

4 4