June 2012 - 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

proposed tz change for Latvia, Lithuania
by Paul Eggert May 25, 2015

May 25, 2015

It's March Madness time for daylight-saving rule changes. Here's a proposed change to the tz database to keep up with the latest political development, which affects time stamps starting March 29: * Latvia and Lithuania will not observe DST, starting this year. Thanks to Andrei Ivanov for this info. =================================================================== RCS file: RCS/europe,v retrieving revision 2000.3 retrieving revision 2000.3.0.1 diff -pu -r2000.3 -r2000.3.0.1 --- europe 2000/03/04 15:31:08 2000.3 +++ europe 2000/03/08 17:48:59 2000.3.0.1 @@ -1135,6 +1135,12 @@ Link Europe/Rome Europe/San_Marino # 1997-01-21 on transition to Summer time ... established the same order of # daylight savings time settings as in the States of the European Union. +# From Andrei Ivanov (2000-03-06): +# This year Latvia will not switch to Daylight Savings Time (as specified in +# <a href="http://www.lv-laiks.lv/wwwraksti/2000/071072/vd4.htm"> +# The Regulations of the Cabinet of Ministers of the Rep. of Latvia of +# 29-Feb-2000 (#79)</a>, in Latvian for subscribers only). + # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Latvia 1989 1996 - Mar lastSun 2:00s 1:00 S Rule Latvia 1989 1996 - Sep lastSun 2:00s 0 - @@ -1151,7 +1157,8 @@ Zone Europe/Riga 1:36:24 - LMT 1880 3:00 Russia MSK/MSD 1989 Mar lastSun 2:00s 2:00 1:00 EEST 1989 Sep lastSun 2:00s 2:00 Latvia EE%sT 1997 Jan 21 - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb 29 + 2:00 - EET # Liechtenstein # Zone NAME GMTOFF RULES FORMAT [UNTIL] @@ -1178,6 +1185,11 @@ Zone Europe/Vaduz 0:38:04 - LMT 1894 Jun # motion to give up shifting to summer time in spring, as it was # already done by Estonia. +# From Andrei Ivanov (2000-03-06): +# I've heard that Ministers of three Baltic countries on their summit +# somewhere in February decided not to switch to summer time starting from +# this spring. + # Zone NAME GMTOFF RULES FORMAT [UNTIL] Zone Europe/Vilnius 1:41:16 - LMT 1880 1:24:00 - WMT 1917 # Warsaw Mean Time @@ -1192,7 +1204,8 @@ Zone Europe/Vilnius 1:41:16 - LMT 1880 2:00 C-Eur EE%sT 1998 2:00 - EET 1998 Mar 29 1:00u 1:00 EU CE%sT 1999 Oct 31 1:00u - 2:00 EU EE%sT + 2:00 EU EE%sT 2000 Feb + 2:00 - EET # Luxembourg # Whitman disagrees with most of these dates in minor ways; go with Shanks.

5 5

Adding Asia/Beijing timezone into the database
by Daoming Qiu Dec. 6, 2014

Dec. 6, 2014

"Beijing Time" is the standard time used for China region, so it is very strange that tzdatabase doesn't have timezone called Asia/Beijing. Strongly suggest to add "Asia/Beijing" zone into the database, and its information is very similar with "Asia/Shanghai".

14 17

a patch for zic.c to allow 'follow rules'
by Alois Treindl Sept. 10, 2013

Sept. 10, 2013

Dear Arthur, I have been preparing a small modification for zic.c which will allow it to understand a 'follow rule' in zone files, like this: # experimental table for Geneva, to test the 'follow' mechanism Zone Europe/Geneva 0:24:37 - LMT 1848 Sep 12 0:24:37 - GET 1894 Jun # Geneva MTime 0 follow Europe/Zurich For test purposes, one can simply insert this zone in the europe file. The feature is helpful in the extension of tzdata to cover complete timezone history. For this purpose, about 1000 additional zone files need to be written, and to be maintained. The process to do so has started in the astrological community, as it needs a complete pre-1970 timezone history. I will not bother you with details. I intend to help creating and maintaining a set of files like 'europe_hist', 'asia_hist' etc which contain the additional zones. The 'follow rule' will allow to keep these extra zone files very small, as usually the additional zones will all have a cross-over moment into a regular tzdata zone. I have for the moment called the modified zic source file zicx.c and prepared a patch file for zic.c to implement the 'follow rule' feature. I have tried to keep the modification very small. Please have a look at the patch, and check for the errors I have probably made. Description of the code: ------------------------ The follow rule must be the last line in a zone, and recursion is not allowed. It is parsed in inzsub() which reacts on GMTOFF = 0 and the word 'follow' in the RULE field. The zone line is stored in zones[] with a special value z_gmtoff = FOLLOW_MARK and the zone_name to follow in field z_rule (which is abused for this purpose). Before the call to outzone() the two sets of zone lines are patched together in a temporary array, so that outzone() and all functions deeper down() need not be modified. Patch ----- --- zic.c 2011-03-09 20:41:27.000000000 +0100 +++ zicx.c 2011-08-25 16:09:04.000000000 +0200 @@ -262,6 +262,17 @@ static int typecnt; #define YR_MAXIMUM 1 #define YR_ONLY 2 +/* +** follow rules, added by Alois Treindl August 2011 +** Zones may end with a line: 0 follow zone_name +** which the parser will represent with FOLLOW_MARK in z_gmtoff, +** and the zone name in z_rule. +** Before the call to outzone() the zone and its follow zone will be +** patched together, so that outzone() sees a regular zone array. +** To keep zone files readable, follow rules cannot be used recursively. +*/ +#define FOLLOW_MARK 999999 + static struct rule * rules; static int nrules; /* number of rules */ @@ -589,7 +600,48 @@ _("%s: More than one -L option specified */ for (j = i + 1; j < nzones && zones[j].z_name == NULL; ++j) continue; - outzone(&zones[i], j - i); + if (zones[j -1].z_gmtoff == FOLLOW_MARK) { + /* copy zone and follow zone into one new array */ + int k,n,m, nrows; + struct zone *xzones, *zp; + nrows = j - i - 1; + zp = &zones[j - 1]; /* line with the follow rule */ + xzones = (struct zone *) (void *) emalloc((int) (nrows * sizeof *xzones)); + for (k = 0; k < nrows; k++) + xzones[k] = zones[i + k]; + /* now find the follow zone in array zones[] */ + for (m = 0; m < nzones; m++) { + if (zones[m].z_name != NULL && strcmp(zp->z_rule, zones[m].z_name) == 0) break; + } + if (m == nzones) { /* error, follow zone not found */ + char *cp; + cp = emalloc(80 + strlen(zp->z_rule) + strlen(zones[i].z_name));; + sprintf(cp, "For zone %s follow zone %s not found, no zonefile created.", zones[i].z_name, zp->z_rule); + eat(zp->z_filename, zp->z_linenum); + error(cp); + ifree(cp); + ifree((void *)xzones); + } + /* now find the next date in the follow zone */ + for (n = m + 1; n < nzones; n++) { + if (zp->z_untiltime < zones[n].z_untiltime) break; + } + /* missing errorcode for case n == nzones, + * assume we are still in same follow zone. + * The follow zone part we need starts at zones[n]. + * Now find where follow zone ends, will be m. + */ + for (m = n; m < nzones && zones[m].z_name == NULL; ++m) + continue; + xzones = (struct zone *) (void *) erealloc((char *) xzones, (int) ((nrows + m - n) * sizeof *xzones)); + for (k = 0; k < m - n; k++) + xzones[nrows + k] = zones[n + k]; + nrows += m - n; + outzone(&xzones[0], nrows); + ifree((void *) xzones); + } else { + outzone(&zones[i], j - i); + } } /* ** Make links. @@ -784,7 +836,7 @@ associate(void) } for (i = 0; i < nzones; ++i) { zp = &zones[i]; - if (zp->z_nrules == 0) { + if (zp->z_nrules == 0 && zp->z_gmtoff != FOLLOW_MARK) { /* ** Maybe we have a local standard time offset. */ @@ -1079,11 +1131,23 @@ const int iscont; return FALSE; } } - z.z_rule = ecpyalloc(fields[i_rule]); - z.z_format = ecpyalloc(fields[i_format]); - if (max_format_len < strlen(z.z_format)) - max_format_len = strlen(z.z_format); - hasuntil = nfields > i_untilyear; + /* check for 0 follow zonename + ** zonename must contain at least one /, and follow must be + * 'follow' or an abbreviation thereof. + */ + if (z.z_gmtoff == 0 && strchr(fields[i_format], '/') != NULL + && itsabbr(fields[i_rule], "follow")) { + z.z_gmtoff = FOLLOW_MARK; + z.z_rule = ecpyalloc(fields[i_format]); + z.z_format = ""; + hasuntil = FALSE; /* no continue of zone now */ + } else { + z.z_rule = ecpyalloc(fields[i_rule]); + z.z_format = ecpyalloc(fields[i_format]); + if (max_format_len < strlen(z.z_format)) + max_format_len = strlen(z.z_format); + hasuntil = nfields > i_untilyear; + } if (hasuntil) { z.z_untilrule.r_filename = filename; z.z_untilrule.r_linenum = linenum;

1 1

Russia may move it's clocks back 1 or 2 hours
by Alexander Krivenyshev June 28, 2012

June 28, 2012

According to different news (in Russian), Russian State Duma is considering the introduction of a permanent winter time with moving its clocks back 1-2 hours. The bill on the transition from summer to winter time will be finalized and submitted to Russian State Duma in early September. http://www.worldtimezone.com/dst_news/dst_news_russia44.html Alexander Krivenyshev, http://www.worldtimezone.com

1 0

Coordinates for America/Sitka in zone.tab?
by OvV_HN June 26, 2012

June 26, 2012

In reply to: [tz] Coordinates for America/Sitka in zone.tab? Alan Mintz Alan_Mintz+TZ_IANA at Earthlink.net Tue Jun 26 07:26:52 UTC 2012 I was under the impression, from the few that I look at on a map, that the coordinates in zone.tab were supposed to be approximately where the name of the zone and the most well-known place is. America/Sitka puzzles me, though. At 57 10 35, -135 18 07, the point is in the water of Katlian Bay, about 150m offshore of a seemingly uninhabited area. The point is 14 km from Sitka. Should this be changed to 57d03'06", -135d20'19"? Reply: Your reference? The Geonames server: http://www.geonames.org/search.html?q=sitka&country=US says: United States, Alaska Sitka City and Borough seat of a second-order administrative division population 8,881, elevation 8m N 57° 3' 11'', W 135° 19' 48'' Which seems better than a place with wet feet! So, please change zone.tab someday..... Oscar van Vlijmen

2 1

Coordinates for America/Sitka in zone.tab?
by Alan Mintz June 26, 2012

June 26, 2012

I was under the impression, from the few that I look at on a map, that the coordinates in zone.tab were supposed to be approximately where the name of the zone and the most well-known place is. America/Sitka puzzles me, though. At 57 10 35, -135 18 07, the point is in the water of Katlian Bay, about 150m offshore of a seemingly uninhabited area. The point is 14 km from Sitka. Should this be changed to 57d03'06", -135d20'19"? -- Alan Mintz <Alan_Mintz+TZ_IANA(a)Earthlink.net>

1 0

Bug report: "Asia" timezone
by Boruch Baum June 19, 2012

June 19, 2012

I was recently showing off ... and I entered the following command $ date && TZ=Asia/Moscow date Tue Jun 19 15:48:14 EDT 2012 Tue Jun 19 19:48:14 Asia 2012 My initial reaction, besides some embarrassment at getting the continent wrong (and most of Russia's timezone are in Asia), is that this is a bug in the coreutils date command. However, I thought it would be of interest to members of the list. It's a double bug. It's printing out a non-existent timezone, and it's using GMT for "Asia" -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

2 1

tz abbreviations / zdump for programmers
by Boruch Baum June 19, 2012

June 19, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings y'all, I have a bit of a long (inaugural) post here to describe my interest in joining this list, and what I might be able to contribute to the greater glory of tz-correctness. BTW, as part of my 'due diligence' before posting this, I read/scanned a selection of the collection of detailed comments in the glibc-2.13/timezone files, as well as the timezone entry in glibc-2.13/FAQ. I'm very glad those comments are there. CONTENTS ======== 1] The app/library I develop/maintain 2] End users' stubborn insistence on using tz abbreviations 2.1] zone.tab modification proposal 2.2] zone.abbr.tab proposal 3] The 'zdump' programmer's function I 'need' to write 1] The app/library I develop/maintain ===================================== libhdate is a FOSS collection for Hebrew time/date 'stuff', for which time zone data and location coordinates are important because: 1) we have about a dozen significant astronomical times-of-day that need to be mapped to a correct local clock time at any particular location; 2) users want that information for future and past dates, and; 3) users want that information for locations in other parts of the globe. This FOSS collection is under active development and versions are available from sourceforge and the Debian GNU/Linux repositories. There are unrelated, closed-source, alternatives available (eg. kaluach for windows and java, and dostagfarlinux for, um, linux). 2] End users' stubborn insistence on using tz abbreviations =========================================================== ... and who can blame them, when that's all they hear in the media. This leaves me in a bind, because if I accept a tz abbreviation as a user input, I have two undesirable options: 1) I could scan ALL the ~420 tzif files for matches and, if I discover that the tz abbrev is not unique, either make an educated guess (based upon the user's locale definition which often will include a country code and a language) or prompt the user for clarification; or 2) I could pre-compile a list that suits my parochial needs, and update my list anytime the tzdata package is updated (and still have to occassionally guess or prompt the user). Then I said to myself, "self, you can't be the only one out there facing these users - go consult and find a global solution". Following are two proposals. Neither may be perfect, but each may make life alot easier for many... 2.1] zone.tab modification proposal =================================== Add a new column/field to this file, in the format: {{;xxx:nnnnn;xxx:nnnnn;...;}} where: xxx is a tz abbreviation nnnnn is the UTC offset for that abbreviation. The use of ";", ":", and braces are to simplify the task of parsing the data programmatically. Advantages: 1) All information for a timezone on a single line (ie. in a single record). 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) Disadvantages: 1) Long line(record) length 2) Messing with the format of an existing file, upon which others may depend 3) Requires change to whatever script/program is used to compile the file for release 2.2] zone.abbr.tab proposal =========================== Create a new text file, say /usr/share/zoneinfo/zone.abbr.tab, sorted by tz abbreviation, with a format like: tz_abbrev country_code localedef useful for setting $LC_TIME and for language matching is_dst if yes, this would have the abbreviation of the non_dst version of this tz. utc_offset historical_only (y/n) - ie. whether currently in use. full_name of the abbreviation, not of the 'real' tz name. Advantages: 1) Easy to find matches for users' pesky (short and convenient-to-type) tz_abbr 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) 3) Includes additional useful information (is_dst, historical_only, full_name, locale_def) 4) Doesn't mess with existing files Disadvantages: 1) It's a new file. 2) Requires new script/program to compile the file for release 3] The 'zdump' programmer's functiion I 'need' to write ======================================================= This section isn't directly related to the above. I don't NEED to write a 'zdump' programmer's functiion; I WANT to, because I remember when a 4Mhz clock speed was wicked fast, and using the current glibc time functions for my libhdate collection would be tremendously wasteful, although today's users will probably never notice. For this section, the reason I want to consult with members of this list (and I appreciate you having read this far) is to make the function as universally useful as possible (it will be FOSS/GPL3+) . My current plan is: int zdump( /// returns TRUE on success, FALSE on failure const char* tzname, /// fully-qualified time-zone name /// (eg. Asia/Baku) const time_t start, /// seconds from epoch to be scanned const time_t end, /// seconds from epoch to be scanned int* num_entries, /// upon successful return, int will contain /// the number of dst transitions + 1, /// for the interval 'start' to 'end'. /// The first entry will always be the /// tz state at time_t start. /// Returns 0 on failure. void* return_data /// upon successful return, will contain a pointer to a malloc()ed space of /// 'num_entries' of 'tzinfo' data, as /// described below, sorted in ascending /// chronological order. /// Returns NULL on failure. ) tzinfo { time_t start /// seconds from epoch int utc_offset /// in minutes, or maybe seconds. char is_dst /// 0/1 char[] tz_abbrev /// const char end_mark /// '\0' } - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPzM3HAAoJEDvrUfDmCx9LbJ4P/RMD+8KWkXxrLtpivyQVz6Yv h88mWjwfeTpb7laT4yeg726YYUQEDfhueLFELRTpxR6aAIAW7fBZEu6UwEMSsxHe UaQdx/xc/03aei/AG6z31u0C+arA40qs8twxEw5pdyHfvBxhQh0YOxO+dl01+zmg w4Y+Mlyd72QmAZ+pdIc5l2L/nTh9L+YnlmPxsXoomYSTh+9kigOxS5JZVMu2sYy6 7FGMj+mybrtru12qwJmoFG2hNjVgy0zKSuJ1HOXmqi5JKBNthlsfkyV4E9vzSGWC PkkbI8R0adGnqKa9faHQxFG+jV+K5Fjscr3eabBi8IYHG+cGYOL6vD0KkNFbHRQf wLRGpkkMjoJm9cxJ7f17wcQFtYFKjcDLIqqtDuT7LhHJ7iF2x4lTqd4YjvpA6rqN fcD+4TNfm8Na5bNbKNJqvWy+Od46wSNqFOiUf9NQaWsUZx/yiXjw1Sl4Jqi7/2Sg A3rc2bcw02Co80bWA+lsMbZUL5NJlQAdfWCKe7xafdILX8PPbe0CaTHzNUFd4vR9 70AJsq6teBivVHossldNlQfsK+S4HmcSMGPt1AuANjGUv0ZoCveR71Ewt0D2wbi4 hSEaSI/P3MVSsFRMJZIoMXlFTuF6d6qItoRvmHrLdU2u5f1+Kjbt7tH0eMOrcdm9 BUi/N3QtrJkU6vWXjLal =n4Kd -----END PGP SIGNATURE-----

16 30

Re: [tz] Are these valid timezone definitions?
by Tadashi Abe June 15, 2012

June 15, 2012

Hi, sorry to interrupt with newbie question. david singleton wrote: >When I define a timezone with export >TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" >there is no change in time when daylight savings ends. > >Is this a known problem? Or a problem with how the timezones are defined? Now I'm testing DST start/end by setting the actual system clock as same as the above method and get the same issue. 1. export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" 2. set system clock just 5 seconds prior to DST [start|end] 3. 5 seconds later, check if switch between DST and STD occurs, but not. As the comment from Zefram, it works when I check date with -d option. http://mm.icann.org/pipermail/tz/2012-June/018059.html >It's always difficult to test timezone offset issues when you're >stating the test times in local time. By the way, your testing method >of modifying the system clock is problematic. It's much better to use >the -d option of GNU date to display a particular time without touching >the clock. Why doesn't it work well when I try to test by modifying the actual system clock? -- Tadashi Abe

3 2

Re: [tz] Patch - America/Los_Angeles zone comment
by Steve Jones June 14, 2012

June 14, 2012

At 13:30 6/9/2012, OvV_HN wrote: >Regarding Malheur county in Oregon: you could add: the _northern_ >part of Malheur county. Here is an image that reflects the borders of Malheur county as well as the time zone border in the area: <http://ontimezone.com/images/malheur.gif>http://OnTimeZone.com/images/malheur.gif The portion of the time zone border that bisects Malhuer county starts on the western border of the county at the southwest corner of T. 35 S., R. 37 E., and runs due east to the eastern border of the county. There is no obvious manmade, political, or geographic feature that further reflects or indicates that portion of the time zone border. Cheers, Steve Jones OnTimeZone.com

3 2

Another Newbie question
by Donald MacQueen June 12, 2012

June 12, 2012

The background is that I have added timezone support to our multi-platform application. To test our app on Windows, I used zoneinfo copied from a Fedora distribution, and I have 143 units tests that test time zones like 'right/America/Detroit', 'posix/America/Detroit', 'US/Eastern', and 'America/Detroit'. But when I run 'for f in *; do zic -d someOutputDir $f;done' on the latest data from iana.org, I get 'America/Detroit' but not 'right/America/Detroit', 'posix/America/Detroit', or 'US/Eastern'. How come? How are they generated on Linux OS's? Thanks -- Donald [|] A bad day in [] is better than a good day in {}

2 1

Patch - America/Los_Angeles zone comment
by OvV_HN June 9, 2012

June 9, 2012

In reply to: [tz] Patch - America/Los_Angeles zone comment Alan Mintz Alan_Mintz+TZ_IANA at Earthlink.net Fri Jun 8 21:27:24 UTC 2012 .... Alternatively, more accuracy could be provided by the following changes: < northamerica > northamerica.new 395,397c395,398 < # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, < # and the northern three-quarters of Idaho county), < # most of Nevada, most of Oregon, and Washington --- > # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, > # the towns of Burgdorf and Warren, and the part of Idaho county > # lying north of the Salmon River), Nevada (except for West Wendover) > # Oregon (except for part of Malheur County), and Washington REPLY: This confuses me. I believe that the state of Idaho has a county named Idaho with a Salmon River running through it. The federal timezone law stipulates that south of this river Mountain Time is in effect, north of it Pacific Time. There are only a couple of places in the southern part of Idaho county, and Burgdorf and Warren are indeed two of them. Why don't we stay with the legal description, stating north/south of Salmon River? Regarding Malheur county in Oregon: you could add: the _northern_ part of Malheur county. Oscar van Vlijmen

1 0

Idea for internationalized time point unique time zone abbreviations
by Tobias Conradi June 8, 2012

June 8, 2012

== INTRODUCTION == If time zone abbreviations for a given point in time are unique they can be used to faster find IANA time zones. The current abbreviations are not unique, e.g. IST could stand for Indian Standard Time and for Israel Standard Time. Since the IANA time zone database cutoff point is 1970-01-01T00:00:00Z and the first publication of ISO 3166 alpha-2 country codes occurred in the early 1970s, one could easily use the country codes to separate sets of abbreviations between countries. One rule sometimes used in the IANA time zone database for creating new abbreviations is to use the ISO alpha-2 country codes. The idea presented here applies such a rule rigidly. Apart from that the idea presented also applies rigid rules for marcation of offset changes like daylight saving time. == Features == One can derive the country of the time zone to which the abbreviation belongs from the abbreviation and from knowledge of the current ISO country code for that country. This is not possible with current IANA time zone database abbreviations like CET, IST, EDT, GALT, EAST, CT (e.g. Cuba Time), CUT (1924 Central Ukraine Time). One can group the abbreviations by country, alone by alphabetic sorting of the abbreviations. This is not possible with current IANA time zone database abbreviations like CST (US), CT (Cuba), PST (US). If the year is known, one can identify the time zone for any given abbreviation. This is not possible with current IANA time zone database abbreviations like IST. Reduces the number of IANA time zones for some abbreviations, e.g. IST is used for Asia/Jerusalem, Asia/Kolkata, while INCT/INZT would only refer to Asia/Kolkata. == DEFINITIONS == === D0) General === D0.1) DST - Daylight saving time D0.2) Format: "<CC><LC><(OC)>T" #abbreviations would be four or five letters long. Details in D1 to D4. === D1) CC - country code and similar === - ISO alpha-2 country code or, - a special code like "EU" or, - a code from the private use area to define larger regions, e.g.: -- XA - ASEAN -- XE - "East" for UTC offsets zones having positive offset -- XW - "West" for UTC offsets zones having negative offset -- ZZ - the whole world, used for UTC and UTC offset zones, details see examples. === D2) LC - location code and similar === D2.1) A character from the set [A-Z], unique for each real time zone within the country. Preferably not from the set [SDF] or any letter agreed in D3 for offset changes D2.2) A character from the set [0-9] for numbered zones, e.g. in Russia. D2.3) The letter C (Common Time) for the most common time, maybe also N derived from "National Time". D2.4) The letter Z could be used if there is only one time zone. Could be dropped for countries that only have one zone, but mandatory per D0.2). D2.5) For UTC offset zones that start with ZZ, when using date-time group (DTG) letters, the letter G - not the letter L to make changing into or from E harder. Otherwise either E for East or W for West, as defined in D1. === D3) OC - seasonal offset code and similar === D3.1) for DST a letter from the set [SD], preferably "D" since "S" in some contexts stands for "standard time" So even if in Europe the term "summer time" is more common, the preferred presentation uses unambiguous"D" D3.2) For wartime maybe the letter W or F as in forward time, W in D2 stands for West. D3.3) For double summer time - to be defined, maybe M for midsummer time D3.4) For absence of any extra rules "standard time", the letter Z is optional. D3.5) For UTC offset zones: a digit. === D4) T === As currently done in English to indicate "Time". == EXAMPLES == === E1) No DST === CUCT - Cuba (Common) Time#in IANA tzdb northamerica 8.54 is CT THCT - Thailand (Common) Time USET - US Eastern Time USCT - US Central Time USPT - US Pacific Time CAET - Canada Eastern Time CLCT - Chile (Common) Time #Continental Time CLET - Chile Eastern Time #Easter Islands, which in the IANA tzdb is EAS%sT ECCT - Ecuador (Common) Time #Continental Time ECGT - Galapagos Time #which in the IANA tzdb is GALT RUOT - Omsk Time #in IANA tzdb is OMST, could be read as Oman Summer/Standard Time RUMT - Moscow Time #Maybe RUCT - Russia Central/Common Time or RUNT - Russia National Time RUKT - Kaliningrad Time RUIT - Irkutsk Time RUVT - Volgograd Time #in IANA tzdb was VOLT Optional: RU1T - Russia First Time Zone Optional: RU2T - Russia Second Time Zone EUCT - Central European Time #Some countries that use this time, are not in the EU. EUWT - Western European Time #See comment for EUCT EUET - Eastern European Time #See comment for EUCT XACT - ASEAN Common Time XE01T - UTC+01 XE08T - UTC+08 XE13T - UTC+13 XW06T - UTC-06 XW11T - UTC-11 ZZZT - UTC ZZE1T - UTC+01 ZZE8T - UTC+08 ZZEAT - UTC+10 # A = hexadecimal for 10 ZZEDT - UTC+13 # A = hexadecimal for 13 ZZW6T - UTC-06 ZZWBT - UTC-11 # B = hexadecimal for 11 #Letters from the NATO(?) date-time group #taken from http://de.wikipedia.org/wiki/Date_Time_Group ZZGZT - UTC±00 ZZGAT - UTC+01 ZZGHT - UTC+08 ZZGKT - UTC+10 ZZGST - UTC-06 ZZGXT - UTC-11 === E2) With DST === #for meaning of the third letter see section E2 USEDT USCDT USPDT CAEDT RUMDT # Daylight saving time or "decree time" EUCDT #preferred as defined in D3.1 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

13 35

Patch - America/Los_Angeles zone comment
by Alan Mintz June 8, 2012

June 8, 2012

I'd like to try this once more without it getting buried or expanded into other issues, please. As it's written, the America/Los_Angeles comment in northamerica v8.54 in tzdata release 2012c does not make sense. The simple solution is to remove 7 characters from line 395: < northamerica > northamerica.new 395c395 < # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, --- > # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, Alternatively, more accuracy could be provided by the following changes: < northamerica > northamerica.new 395,397c395,398 < # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, < # and the northern three-quarters of Idaho county), < # most of Nevada, most of Oregon, and Washington --- > # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, > # the towns of Burgdorf and Warren, and the part of Idaho county > # lying north of the Salmon River), Nevada (except for West Wendover) > # Oregon (except for part of Malheur County), and Washington AFAIK, this description is completely accurate (though it doesn't reflect unofficial observances in Nevada, which I assume wouldn't be appropriate here).

1 0

Indonesia - A government committee is proposing a single time zone
by Tobias Conradi June 7, 2012

June 7, 2012

http://www.thejakartapost.com/news/2012/05/26/single-time-zone-may-begin-la… -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

4 4

may be a small mistake in the localtime.c code
by Z V June 6, 2012

June 6, 2012

Hello, The next piece of code looks like a mistake: localtime.c (1477-1484) while (i > 0 && sp->lsis[i].ls_trans == *sp->lsis[i - 1].ls_trans + 1* && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { ++hit; --i; } As far as I understand here are processed 'Leap' rules with '++' correction. If so, sp->lsis[i].ls_trans must be equal to sp->lsis[i - 1].ls_trans. BR, Igor

3 2

Are these valid timezone definitions?
by david singleton June 6, 2012

June 6, 2012

I posted a question earlier about a problem with exporting TZ, which was caused by a typo in the timezone man page on my ubuntu 10.10 system. When the typo was fixed the daylight savings end worked correctly. I've been given a new test in which one case seem to show a problem of when daylight savings starts, and one case when daylight savings ends. When a timezone is defined as : export TZ="NZST-23:00:00NZDT-24:00:00,M10.1.0,M3.3.0" the time is set one hour ahead when daylight savings begins. When I define a timezone with export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" there is no change in time when daylight savings ends. Is this a known problem? Or a problem with how the timezones are defined? I'll attach the test case. thanks Dave

3 2

Re: [tz] FW: may be a small mistake in the localtime.c code
by Arthur David Olson June 6, 2012

June 6, 2012

For (so far unused in the real word) double leap seconds, the binary file has different values for successive ls_trans/ls_corr pairs. For example, if the current "leapseconds" is changed so that the upcoming leapsecond is a double, a la... Leap 2012 Jun 30 23:59:60 ++ S ...then there will be an an entry with an ls_trans value of 1341100824 and an ls_corr value of 25 followed by an entry with an ls_trans value of 1341100825 and an ls_corr value of 26. Bottom line: Bradley White's code should be okay. --ado ________________________________________ From: Z V [igt31415926(a)gmail.com] Sent: Thursday, May 24, 2012 6:02 AM To: tz(a)iana.org Subject: [tz] may be a small mistake in the localtime.c code Hello, The next piece of code looks like a mistake: localtime.c (1477-1484) while (i > 0 && sp->lsis[i].ls_trans == sp->lsis[i - 1].ls_trans + 1 && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { ++hit; --i; } As far as I understand here are processed 'Leap' rules with '++' correction. If so, sp->lsis[i].ls_trans must be equal to sp->lsis[i - 1].ls_trans. BR, Igor

1 0

zone identifiers
by Tobias Conradi June 6, 2012

June 6, 2012

was: tz abbreviations / zdump for programmers On Tue, Jun 5, 2012 at 4:34 PM, Petr Machata <pmachata(a)redhat.com> wrote: > FWIW, in Czech Republic in particular, CET is translated as "SEČ" > (středoevropský čas), CEST as "SELČ" (~ letní ~). So apparently, these > things get translated. So are zone identifiers: Europe/Prague, for > example, should be presented to a Czech user as "Evropa/Praha", or some > such (the slash may be understandable, but maybe it should be somehow > localized away as well). So you do need translations of these strings. > Even to English, as a matter of fact: "Africa/Addis_Ababa" should > probably be presented as "Africa/Addis Ababa". I think that the > situation with abbreviations is similar. Identifiers are /not/ in English, like ISO country codes, or ISO language codes are /not/ in English. Not even the components are defined to be in English: America/Bahia_Banderas - Bahia de Banderas Antarctica/DumontDUrville - Dumont d'Urville Station Indian/... - Indian Ocean -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

2 1

bug in export TZ where day light savings spans Dec 31st?
by david singleton June 6, 2012

June 6, 2012

When I use the example from the timezone man page to define, and export a local TZ variable: export TZ="NZST-12.00:00NZDT-13:00:00,M10.1.0,M3.3.0" And then set the date to December 31st at 23:59 I see the clock roll over to 00:00 normally. But when I define a timezone using a positive offset I see time get set backwards at December 31st. I believe time should not get set back on December 31st for any timezones whose day light savings span December 31st. export TZ="NZST+12.00:00NZDT+13:00:00,M10.1.0,M3.3.0" date 123123592011.55 Sat Dec 31 23:59:55 2011 when I wait 5 seconds and check the date again I see the date has been adjusted to Dec 31st at 12:00? root@dstest2:~# date Sat Dec 31 12:00:01 NZST 2011 What is happening with TZs defined with a positive offset? I can reproduce this on Linux systems using glibc 2.5.90 up through glibc 2.12.1. I was hoping you could help me understand what is going on? thank you Dave

5 6

Let's keep focused on the time zone code and data
by Paul Eggert June 6, 2012

June 6, 2012

I'd like to ask people to keep the email focused on the time zone code and data, and not engage in personal attacks, worry about which Wikipedia user did what, etc.

1 0

mailing list, tone, respect, bugs, suggestions
by Tobias Conradi June 6, 2012

June 6, 2012

was: Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate On Wed, Jun 6, 2012 at 4:01 AM, David Patte <dpatte(a)relativedata.com> wrote: > I think this is the biggest issue with Conradi. I believe he has made 'some' > valuable comments and contributions over the last month (some - but not > all), Who sent more new bug reports and reminders of previously reported bugs than me? >but his attitude has turned the majority of this list against him What is your source for that. Maybe at first you could release a number of how many subscribers are on the list? > whether he has any points that have any merit or not. That would tell more about others than about me. > Mr. Conradi, if you so dearly want to 'fix bugs' in the db, as much as we > all do, I don't know how much all others do. I see no fix by the current TZ Coordinator at all. > I would suggest you learn how to present your suggestions as just > that - suggestions - and with humility. Why humility? Does that change the facts? >Maybe its an issue you have with translation, > or perhaps something else, but your presentation has turned > most people off providing you any futrther support for your ideas. Regrettably, because I think I sometimes make errors and am happy to learn from feedback. > You would > have gotten a lot further by granting those that have been on this list as > contributors or maintainers some respect; So you mean I didn't grant them some respect? I think I have gotten quite far. I have exposed lots of bugs in the database and in the management. If the management is not happy to hear this, and other people don't see the bugs, or are afraid to raise their voice, then shall I stop raising mine? What's up with the bugs in Siberia? > and I assure you that if you had > done that that you might have gained more consideration for your > 'suggestions'. Siberia stays wrong, despite people knowing it, because the one who reported it didn't show respect? What strange game is that? What's the purpose > If you have a suggestion for the database, please state it as a suggestion, Several instance where I titled emails with Propose/Proposal can be found at http://mm.icann.org/pipermail/tz/2012-May/thread.html The word "suggest" in a title of an email by me can be seen at http://mm.icann.org/pipermail/tz/2011-September/ "Post-1970 errors in Russian zones, suggest zones Asia/Tomsk, Asia/Barnaul " That is Siberia! > and back up your suggestion with documentation Can you show any bug report or proposal by me that came without? > - and stop accusing others of > not doing their part. Where did I do that? I think the only person that has an official part in fixing zone data bugs in the database is the current TZ Coordinator, named Paul Eggert. > That would help us all. "us"? Does that "us" include the users that are confronted with the IANA time zone database bugs? Bouvet Island, Siberia, place vs location, gmt vs utc, tz(a)elsie.nci.nih.gov vs tz(a)iana.org (the latter resulting in bouncing email)...? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0

Re: [tz] Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate
by Alan Mintz June 6, 2012

June 6, 2012

I apologize to the list. I'll try to keep this brief, and I will _not_ engage in a flame war. I have no desire to work with someone who, I've now learned, just cannot be worked with. Constructive comments from others are welcome. At 2012-06-05 17:31, Tobias Conradi wrote: >In Wikipedia several accounts that added Olson/IANA time zone >information have been blocked and marked as sock puppets of Tobias >Conradi. Since User:Tobias Conradi did not edit since years, because a >handful of people once decided to block him, the only evidence for >"sock puppeting" is given as "behavioral". > >Behavioral for the User:TimeOfChange is to edit time articles: >http://en.wikipedia.org/wiki/Special:Contributions/TimeOfChange >No single talk page edit or anything else. > >Lately User Royaume du Maroc got blocked, who created: >http://en.wikipedia.org/wiki/Time_in_Florida Are you denying that you are "Royaume du Maroc" (RdM)? I've known about you for less than a month and it's clear to me that you are he. Give us a break and seek help. Seemingly coincidentally, I did some work on WP at the same time as RdM because I realized there were issues after first reporting to this list about a minor one. He seems fixated on the order in which things happened. I certainly don't care. Take all the credit you want. I simply want to get things right, and you can no longer do that, given that your past actions have you banned indefinitely. >BUT NOW THE REAL PROBLEM. AlanM1 is deleting IANA time zone from >Wikipedia e.g. Shiprock, South_Pole, Longyearbyen, Ljubljana >http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&di… I've spent a bunch of time on this in the last couple of days. I worked with the 2010e release on which the WP data was supposed to be based, and found numerous inconsistencies. Today, I decided that, versus correcting those, I might as well just use the latest data available - 2012c. The list on that page (http://en.wikipedia.org/wiki/List_of_tz_database_time_zones) is now consistent with what comes out of the Perl DateTime::TimeZone package, based on the 2012c release, merged with the zone.tab file from the same release (to get the coordinates and comments, which are not part of the perl package). This is also consistent with the 7 continent files. I still have to explore the relatively small list of diffs (including those you mentioned) to see why they were there before and not now. I suspect they are links. Note that the whole thing is a work in progress. I hardly had time to go get a burger after finishing hours of work on this before your drivel hit the list. >and at the same time introducing >| [[ISO_3166-1:|ISO_3166-1:]] >| >| [[PST8PDT]] > >into a list that claims to be based on a zone.tab listing. PST8PDT is >not in the current zone.tab file. No, it doesn't claim to be based on the zone.tab file. It's based on the 7 continent files. >Also the minus signs are changed into hyphen minuses, so that UTC >offset articles which use the minus sign are now reached via >redirects. OMG, the sky is falling! The way I read WP:MOS, I've used the correct character. The fact that the individual UTC* articles (which you created) use a different character doesn't change that at all. I will, however, investigate. What does this nitpicky bit of WP style have to do with the TZ mailing list? Is it really the right tone to take? >Furthermore the order of the elements in that list is not more the >same as in zone.tab, and the first column that allowed sorting in that >order got removed by AlanM1. Why is that order important? They are in order of the TZ identifier, which is the primary key of the database, and the logical order one would expect a list in, instead of the arbitrary and seemingly purposeless and undocumented number that was there. >Maybe some readers here with an account on Wikipedia can revert the >introduced errors and explain to AlanM1 what the errors are. You have yet to report anything that would be considered an error, and certainly not in a tone that would make anyone want to continue working with you (or at all). >E.g. due to South_Pole removal in the data templates, at >http://en.wikipedia.org/wiki/Time_in_Antarctica >there is now "[[ISO 3166-1:IANA time zone id not in >Template:Tz/country code|IANA time zone id not in Template:Tz/country >code]]" As I said, work in progress. Fixing any broken links is next. >Also due to not using the data templates at >http://en.wikipedia.org/wiki/List_of_tz_database_time_zones >Wikipedia is now open to inconsistency between this list and data >display in other places. Before the change the list showed to a wide >extend the data contained in the templates, so people could easily >check for correctness. I did use those templates, and the data in the individual column templates are now all in sync. The problem is that I was unable to save the template-using version of the "List of tz database time zones" article, apparently because of the resulting complexity of all those template transclusions. If you had read the change log, or given me time to document it on the talk page, you would have seen my note about that: "(Update to 2012c, data added directly to article because of performance problems when templated. This may be a temporary problem - will try again later.)" You never saw this problem because you didn't use the templates for the last 140 or so rows. I spent quite a lot of time on it, trying to reduce the number of transclusions and ultimately gave up, hoping that the problem was temporary. I'll note that your last version of the page (http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&ol…) takes almost a _minute_ to appear, while my current version of it (with the data in the page instead of transcluded) takes about 3 seconds. >If the data in the templates is well maintained then it could be used >in the infoboxes on the city pages, then thousands of articles could >display information offset information obtain from IANA. It is. It was just the "List of tz database time zones" that is unable to use them (for the moment).

3 2

Wikipedia - blocking time zone contributors - massive insertion of errors by AlanM1 - win-win if people cooperate
by Tobias Conradi June 6, 2012

June 6, 2012

In Wikipedia several accounts that added Olson/IANA time zone information have been blocked and marked as sock puppets of Tobias Conradi. Since User:Tobias Conradi did not edit since years, because a handful of people once decided to block him, the only evidence for "sock puppeting" is given as "behavioral". Behavioral for the User:TimeOfChange is to edit time articles: http://en.wikipedia.org/wiki/Special:Contributions/TimeOfChange No single talk page edit or anything else. Lately User Royaume du Maroc got blocked, who created: http://en.wikipedia.org/wiki/Time_in_Florida A listing of states that have more than one IANA time zone http://en.wikipedia.org/w/index.php?title=Time_in_the_United_States&diff=49… http://en.wikipedia.org/wiki/Time_in_Idaho Expanding the listing, maybe to create more state specific articles http://en.wikipedia.org/w/index.php?title=Time_in_the_United_States&diff=49… Then User:AlanM1 jumps in, who later in a discussion when User Royaume du Maroc was already blocked writes http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archiv… "... I created some and edited some other "Time in state" articles for the purpose of specifying exactly which counties (or other divisions) are in which time zones. He jumped on it at the same time, apparently prompted by my email to the tz list" - this AlanM1 seems to be on the tz mailing list. I emailed one Alan (an "Alan Mintz") that is on the list showing that it was the other way around, and AlanM1 jumped on it, but AlanM1 did not fix his claim in WP. Does AlanM1 believe Royaume du Maroc did a time travel? BUT NOW THE REAL PROBLEM. AlanM1 is deleting IANA time zone from Wikipedia e.g. Shiprock, South_Pole, Longyearbyen, Ljubljana http://en.wikipedia.org/w/index.php?title=List_of_tz_database_time_zones&di… and at the same time introducing | [[ISO_3166-1:|ISO_3166-1:]] | | [[PST8PDT]] into a list that claims to be based on a zone.tab listing. PST8PDT is not in the current zone.tab file. Also the minus signs are changed into hyphen minuses, so that UTC offset articles which use the minus sign are now reached via redirects. Furthermore the order of the elements in that list is not more the same as in zone.tab, and the first column that allowed sorting in that order got removed by AlanM1. Maybe some readers here with an account on Wikipedia can revert the introduced errors and explain to AlanM1 what the errors are. E.g. due to South_Pole removal in the data templates, at http://en.wikipedia.org/wiki/Time_in_Antarctica there is now "[[ISO 3166-1:IANA time zone id not in Template:Tz/country code|IANA time zone id not in Template:Tz/country code]]" Also due to not using the data templates at http://en.wikipedia.org/wiki/List_of_tz_database_time_zones Wikipedia is now open to inconsistency between this list and data display in other places. Before the change the list showed to a wide extend the data contained in the templates, so people could easily check for correctness. If the data in the templates is well maintained then it could be used in the infoboxes on the city pages, then thousands of articles could display information offset information obtain from IANA. That way also the tz mailing list could attract more feedback on time zone changes. It could be a win-win for IANA and Wikipedia. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

1 0