Paul Eggert | 29 Jul 09:03 2015

[tz] [PROPOSED PATCH 1/2] * southamerica: Give source for 1965 Venezuela transition.

---
 southamerica | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/southamerica b/southamerica
index dcc063f..dd9235f 100644
--- a/southamerica
+++ b/southamerica
 <at>  <at>  -1734,6 +1734,10  <at>  <at>  Zone America/Montevideo	-3:44:44 -	LMT	1898 Jun 28

 # Venezuela
 #
+# From Paul Eggert (2015-07-28):
+# For the 1965 transition see Gaceta Oficial № 27.619 (1964-12-15), p 205.533
+# http://www.pgr.gob.ve/dmdocuments/1964/27619.pdf
+#
 # From John Stainforth (2007-11-28):
 # ... the change for Venezuela originally expected for 2007-12-31 has
 # been brought forward to 2007-12-09.  The official announcement was
 <at>  <at>  -1745,6 +1749,6  <at>  <at>  Zone America/Montevideo	-3:44:44 -	LMT	1898 Jun 28
 # Zone	NAME		GMTOFF	RULES	FORMAT	[UNTIL]
 Zone	America/Caracas	-4:27:44 -	LMT	1890
 			-4:27:40 -	CMT	1912 Feb 12 # Caracas Mean Time?
-			-4:30	-	VET	1965        # Venezuela Time
+			-4:30	-	VET	1965 Jan  1  0:00 # Venezuela T.
 			-4:00	-	VET	2007 Dec  9  3:00
 			-4:30	-	VET
--

-- 
2.1.4

(Continue reading)

J J | 24 Jul 17:40 2015
Picon

[tz] Uruguay out of DST

>> >> Source: http://www.camtur.com.uy/index.php/noticias/281-se-derogo-decreto-del-cambio-de-horario-de-verano >> That is a press release published by an organization lobbying for the change, >> and surely such a source is less reliable than the newspapers we're already citing. >> The whole thing is very mysterious, at least to this outsider.


Here is the decree signed by the president of Uruguay, on presidency website,

http://archivo.presidencia.gub.uy/sci/decretos/2015/06/cons_min_201.pdf

Kees Dekker | 23 Jul 16:50 2015

[tz] suggestions for potential code improvements?

Hi,

 

I extracted the v2015e code and like to ask some things:

 

1.       Why do you not always initialize the variables that are now passed to the INITIALIZE macro (see date.c/localtime.c/zic.c/private.h)? It has (almost) no impact on performance and prevents strict compilers to complain about (potentially) non-initialized variables. If you assign zero upon declaration, the INITIALIZE macro can go away.

2.       In asctime_r() (asctime.c:72 and later) two arrays are used for week days. These arrays use a size of ‘3’ for a 3-letter weekday. I expect to use an array of ‘4’, because the ‘\0’ character need to fit too, because the wn and mn variables are used in a call to sprintf() (line 106), where sprintf() normally requires to use 0-terminated strings. By using a ‘4’-sized array, this is automatically achieved. I don’t know whether all sprintf() implementations for all operating systems respect the width/size specifier and allow non-0 terminated string. Now a size/width of ‘3’ is specified, which is not needed if the strings are well terminated, or by accident used somewhere else.

 

I really appreciate if you will do something with these suggestions.

 

Regards,

Kees

Jon Skeet | 21 Jul 19:47 2015
Picon

[tz] Lack of "initial" transitions for some zones

I suspect this is just a matter of how the data has been specified, but it's a little odd...

I'm looking at the output of zic for each zone, and almost all zones start with a "transition" for some timestamp in the long distant past - including fixed zones such as UTC and Etc/*.

However, the legacy "root" zones of CET, EET, PST8PDT etc don't have this initial "transition" in the file - unless I'm misinterpreting it, which is always a possibility.

Would it make sense to adjust either the data or zic to make all zic output (in the 8-byte-timestamp format, at least) cover all of time? I realize that this "extra" data (presumably an insertion of "standard time until the first transition") may well not be historically accurate - but I doubt that it would be any less accurate than other zones in a similar situation.

Jon

Paul Eggert | 21 Jul 15:58 2015

Re: [tz] Time Zone City for China

寇含军 wrote:
> if you take a look at the Windows time zone settings dialog, Beijing is in the list, but no Shanghai.

Similarly, if you look at the time zone settings dialog program published by the 
tz project, you'll see "Beijing Time", not "Shanghai Time".  Please see the 
shell transcript at the end of this message.

The string 'Asia/Shanghai' is a tzdata-specific identifier, not intended to be 
visible to non-experts.  It's like 'America/New_York' (which is not the string 
that a non-expert user would expect in Washington DC) or 'Asia/Kolkata' 
(likewise for a non-expert in New Delhi).  If you're selecting time zones via a 
user interface that's showing the string "Shanghai Time", I suggest writing to 
whoever's maintaining that user interface (it's not us :-).

$ tzselect
Please identify a location so that time zone rules can be set correctly.
Please select a continent, ocean, "coord", or "TZ".
  1) Africa
  2) Americas
  3) Antarctica
  4) Asia
  5) Atlantic Ocean
  6) Australia
  7) Europe
  8) Indian Ocean
  9) Pacific Ocean
10) coord - I want to use geographical coordinates.
11) TZ - I want to specify the time zone using the Posix TZ format.
#? 4
Please select a country whose clocks agree with yours.
  1) Afghanistan		  18) Israel		    35) Palestine
  2) Armenia		  19) Japan		    36) Philippines
  3) Azerbaijan		  20) Jordan		    37) Qatar
  4) Bahrain		  21) Kazakhstan	    38) Russia
  5) Bangladesh		  22) Korea (North)	    39) Saudi Arabia
  6) Bhutan		  23) Korea (South)	    40) Singapore
  7) Brunei		  24) Kuwait		    41) Sri Lanka
  8) Cambodia		  25) Kyrgyzstan	    42) Syria
  9) China		  26) Laos		    43) Taiwan
10) Cyprus		  27) Lebanon		    44) Tajikistan
11) East Timor		  28) Macau		    45) Thailand
12) Georgia		  29) Malaysia		    46) Turkmenistan
13) Hong Kong		  30) Mongolia		    47) United Arab Emirates
14) India		  31) Myanmar (Burma)	    48) Uzbekistan
15) Indonesia		  32) Nepal		    49) Vietnam
16) Iran		  33) Oman		    50) Yemen
17) Iraq		  34) Pakistan
#? 9
Please select one of the following time zone regions.
1) Beijing Time
2) Xinjiang Time
#?

David Patte ₯ | 20 Jul 06:10 2015

[tz] About the core city of a tz region

I am curious about the protocol that tz uses to specify the name of each 
tz region.

Is the core city in a region always the most populous city in the tz region?

And what is done if a smaller city's population overtakes the named 
city? Is the zone renamed?

Also, since historical data (pre-1970) is now maintained only for the 
named city in a region, does it not make sense to use the population as 
of 1970, since the historical records actually affected more people at 
that time?

William Roberts | 20 Jul 05:56 2015

[tz] Full timezone names

Hi
I'm currently using the tz data that comes with PHP. Is there a way of retrieving the full timezone name from the tz database, eg. Central European Time, Eastern Standard Time etc.

So far I haven't been able to, so am using the CLDR repository which assigns a metazone to each timezone from the tz database, and from that I can get the full timezone name but it's not ideal as they don't always match exactly with the abbreviations from the tz data.

Are there any plans to enable the full timezone names to be retrieved from the tz database the same way you would the abbreviations in PHP for example, or is getting them from the CLDR repository the best way to go about it?

Thanks.
Paul Eggert | 20 Jul 05:23 2015

[tz] [PROPOSED PATCH] Support %z in Zone formats

This extends the zic input format to add support for %z, which
expands to a UTC offset in as-short-as-possible ISO 8601 format.
It's intended to better support zones that do not have an
established abbreviation already.  This is a change only to zic;
it does not affect the data, which can still be compiled with
older zic versions.
* NEWS, zic.8: Document this.
* zic.c (struct zone): New member z_format_specifier.
(PERCENT_Z_LEN_BOUND): New constant.
(max_abbrvar_len): Initialize to it, rather than to 0.
(associate, inzsub, doabbr): Add support for %z.
(abbroffset): New function.
(doabbr): 2nd arg is now struct zone *, not a char *.
All callers changed.
---
 NEWS  |  5 +++++
 zic.8 | 13 +++++++++++
 zic.c | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 3 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/NEWS b/NEWS
index b7593e7..9eff28c 100644
--- a/NEWS
+++ b/NEWS
 <at>  <at>  -25,6 +25,11  <at>  <at>  Unreleased, experimental changes
     (Thanks to Jon Skeet and Arthur David Olson.)  Constraints on
     simultaneity are now documented.

+    The two characters '%z' in a zone format now stand for the UTC
+    offset, e.g., '-07' for seven hours behind UTC and '+0530' for
+    five hours and thirty minutes ahead.  This better supports time
+    zone abbreviations conforming to POSIX.1-2001 and later.
+
   Changes affecting installed data files

     Data entries have been simplified for Atlantic/Canary, Europe/Simferopol,
diff --git a/zic.8 b/zic.8
index dfb01db..94b6753 100644
--- a/zic.8
+++ b/zic.8
 <at>  <at>  -350,6 +350,19  <at>  <at>  The pair of characters
 is used to show where the
 .q "variable part"
 of the time zone abbreviation goes.
+Alternately, a format can use the pair of characters
+.B %z
+to stand for the UTC offset in the form
+.RI \(+- hh ,
+.RI \(+- hhmm ,
+or
+.RI \(+- hhmmss ,
+using the shortest form that does not lose information, where
+.IR hh ,
+.IR mm ,
+and
+.I ss
+are the hours, minutes, and seconds east (+) or west (\(mi) of UTC.
 Alternately,
 a slash (/)
 separates standard and daylight abbreviations.
diff --git a/zic.c b/zic.c
index 6854033..3c4ae93 100644
--- a/zic.c
+++ b/zic.c
 <at>  <at>  -76,6 +76,7  <at>  <at>  struct zone {
 	zic_t		z_gmtoff;
 	const char *	z_rule;
 	const char *	z_format;
+	char		z_format_specifier;

 	zic_t		z_stdoff;

 <at>  <at>  -130,6 +131,9  <at>  <at>  static void	rulesub(struct rule * rp,
 static zic_t	tadd(zic_t t1, zic_t t2);
 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 };
+
 static int		charcnt;
 static bool		errors;
 static bool		warnings;
 <at>  <at>  -139,7 +143,7  <at>  <at>  static bool		leapseen;
 static zic_t		leapminyear;
 static zic_t		leapmaxyear;
 static int		linenum;
-static int		max_abbrvar_len;
+static int		max_abbrvar_len = PERCENT_Z_LEN_BOUND;
 static int		max_format_len;
 static zic_t		max_year;
 static zic_t		min_year;
 <at>  <at>  -955,7 +959,7  <at>  <at>  associate(void)
 			** Note, though, that if there's no rule,
 			** a '%s' in the format is a bad thing.
 			*/
-			if (strchr(zp->z_format, '%') != 0)
+			if (zp->z_format_specifier == 's')
 				error("%s", _("%s in ruleless zone"));
 		}
 	}
 <at>  <at>  -1170,6 +1174,7  <at>  <at>  static bool
 inzsub(char **fields, int nfields, bool iscont)
 {
 	register char *		cp;
+	char *			cp1;
 	static struct zone	z;
 	register int		i_gmtoff, i_rule, i_format;
 	register int		i_untilyear, i_untilmonth;
 <at>  <at>  -1201,13 +1206,21  <at>  <at>  inzsub(char **fields, int nfields, bool iscont)
 	z.z_linenum = linenum;
 	z.z_gmtoff = gethms(fields[i_gmtoff], _("invalid UT offset"), true);
 	if ((cp = strchr(fields[i_format], '%')) != 0) {
-		if (*++cp != 's' || strchr(cp, '%') != 0) {
+		if ((*++cp != 's' && *cp != 'z') || strchr(cp, '%')
+		    || strchr(fields[i_format], '/')) {
 			error(_("invalid abbreviation format"));
 			return false;
 		}
 	}
 	z.z_rule = ecpyalloc(fields[i_rule]);
-	z.z_format = ecpyalloc(fields[i_format]);
+	z.z_format = cp1 = ecpyalloc(fields[i_format]);
+	z.z_format_specifier = cp ? *cp : '\0';
+	if (z.z_format_specifier == 'z') {
+	  if (noise)
+	    warning(_("format '%s' not handled by pre-2015 versions of zic"),
+		    z.z_format);
+	  cp1[cp - fields[i_format]] = 's';
+	}
 	if (max_format_len < strlen(z.z_format))
 		max_format_len = strlen(z.z_format);
 	hasuntil = nfields > i_untilyear;
 <at>  <at>  -1890,19 +1903,59  <at>  <at>  writezone(const char *const name, const char *const string, char version)
 	free(fullname);
 }

+static char const *
+abbroffset(char *buf, zic_t offset)
+{
+  char sign = '+';
+  int seconds, minutes;
+
+  if (offset < 0) {
+    offset = -offset;
+    sign = '-';
+  }
+
+  seconds = offset % SECSPERMIN;
+  offset /= SECSPERMIN;
+  minutes = offset % MINSPERHOUR;
+  offset /= MINSPERHOUR;
+  if (100 <= offset) {
+    error(_("%%z UTC offset magnitude exceeds 99:59:59"));
+    return "%z";
+  } else {
+    char *p = buf;
+    *p++ = sign;
+    *p++ = '0' + offset / 10;
+    *p++ = '0' + offset % 10;
+    if (minutes | seconds) {
+      *p++ = '0' + minutes / 10;
+      *p++ = '0' + minutes % 10;
+      if (seconds) {
+	*p++ = '0' + seconds / 10;
+	*p++ = '0' + seconds % 10;
+      }
+    }
+    *p = '\0';
+    return buf;
+  }
+}
+
 static size_t
-doabbr(char *const abbr, const char *const format, const char *const letters,
+doabbr(char *abbr, struct zone const *zp, char const *letters,
        bool isdst, bool doquotes)
 {
 	register char *	cp;
 	register char *	slashp;
 	register size_t	len;
+	char const *format = zp->z_format;

 	slashp = strchr(format, '/');
 	if (slashp == NULL) {
-		if (letters == NULL)
-			strcpy(abbr, format);
-		else	sprintf(abbr, format, letters);
+	  char letterbuf[PERCENT_Z_LEN_BOUND + 1];
+	  if (zp->z_format_specifier == 'z')
+	    letters = abbroffset(letterbuf, -zp-≥z_gmtoff);
+	  else if (!letters)
+	    letters = "%s";
+	  sprintf(abbr, format, letters);
 	} else if (isdst) {
 		strcpy(abbr, slashp + 1);
 	} else {
 <at>  <at>  -2127,7 +2180,7  <at>  <at>  stringzone(char *result, const struct zone *const zpfirst, const int zonecount)
 	if (stdrp == NULL && (zp->z_nrules != 0 || zp->z_stdoff != 0))
 		return -1;
 	abbrvar = (stdrp == NULL) ? "" : stdrp->r_abbrvar;
-	len = doabbr(result, zp->z_format, abbrvar, false, true);
+	len = doabbr(result, zp, abbrvar, false, true);
 	offsetlen = stringoffset(result + len, -zp-≥z_gmtoff);
 	if (! offsetlen) {
 		result[0] = '\0';
 <at>  <at>  -2136,7 +2189,7  <at>  <at>  stringzone(char *result, const struct zone *const zpfirst, const int zonecount)
 	len += offsetlen;
 	if (dstrp == NULL)
 		return compat;
-	len += doabbr(result + len, zp->z_format, dstrp->r_abbrvar, true, true);
+	len += doabbr(result + len, zp, dstrp->r_abbrvar, true, true);
 	if (dstrp->r_stdoff != SECSPERMIN * MINSPERHOUR) {
 	  offsetlen = stringoffset(result + len,
 				   -(zp->z_gmtoff + dstrp->r_stdoff));
 <at>  <at>  -2307,8 +2360,7  <at>  <at>  outzone(const struct zone * const zpfirst, const int zonecount)
 		startoff = zp->z_gmtoff;
 		if (zp->z_nrules == 0) {
 			stdoff = zp->z_stdoff;
-			doabbr(startbuf, zp->z_format,
-			       NULL, stdoff != 0, false);
+			doabbr(startbuf, zp, NULL, stdoff != 0, false);
 			type = addtype(oadd(zp->z_gmtoff, stdoff),
 				startbuf, stdoff != 0, startttisstd,
 				startttisgmt);
 <at>  <at>  -2400,7 +2452,7  <at>  <at>  outzone(const struct zone * const zpfirst, const int zonecount)
 					if (ktime < starttime) {
 						startoff = oadd(zp->z_gmtoff,
 							stdoff);
-						doabbr(startbuf, zp->z_format,
+						doabbr(startbuf, zp,
 							rp->r_abbrvar,
 							rp->r_stdoff != 0,
 							false);
 <at>  <at>  -2410,7 +2462,7  <at>  <at>  outzone(const struct zone * const zpfirst, const int zonecount)
 						startoff == oadd(zp->z_gmtoff,
 						stdoff)) {
 							doabbr(startbuf,
-								zp->z_format,
+								zp,
 								rp->r_abbrvar,
 								rp->r_stdoff !=
 								false,
 <at>  <at>  -2419,7 +2471,7  <at>  <at>  outzone(const struct zone * const zpfirst, const int zonecount)
 				}
 				eats(zp->z_filename, zp->z_linenum,
 					rp->r_filename, rp->r_linenum);
-				doabbr(ab, zp->z_format, rp->r_abbrvar,
+				doabbr(ab, zp, rp->r_abbrvar,
 					rp->r_stdoff != 0, false);
 				offset = oadd(zp->z_gmtoff, rp->r_stdoff);
 				type = addtype(offset, ab, rp->r_stdoff != 0,
--

-- 
2.1.4

Jon Skeet | 19 Jul 19:24 2015
Picon

[tz] Behaviour in the face of multiple identical rules

This is more of an awareness-raising post than anything else... the data here is very far in the past.

While trying to validate Noda Time against zic, I came up against issues with data releases between 1993 and 1996 in Egypt/Cairo. It turns out that this is because the Egypt rule is duplicated in the asia file, and this affects things.

As a smallish example, if you create a file called testzone like this:

Rule    Egypt   1900    only    -       Oct      1      0:00    0       -
Rule    Egypt   1943    1945    -       Nov      1      0:00    0       -
Rule    Egypt   1945    only    -       Apr     16      0:00    1:00    " DST"
Rule    Egypt   1957    only    -       May     10      0:00    1:00    " DST"
Rule    Egypt   1957    1958    -       Oct      1      0:00    0       -
Rule    Egypt   1958    only    -       May      1      0:00    1:00    " DST"
# Rule  Egypt   1957    only    -       May     10      0:00    1:00    " DST"

# Zone  NAME            GMTOFF  RULES   FORMAT  [UNTIL]
Zone    Africa/Cairo    2:05:00 -       LMT     1900 Oct
                        2:00    Egypt   EET%s

... then execute:

$ zic -d . testzone && zdump -v -c 1955,1958 $PWD/Africa/Cairo

You'll see output like this for the May 1957 transition:

.../Africa/Cairo  Thu May  9 21:59:59 1957 UT = Thu May  9 23:59:59 1957 EET isdst=0 gmtoff=7200
...Africa/Cairo  Thu May  9 22:00:00 1957 UT = Fri May 10 01:00:00 1957 EET DST isdst=1 gmtoff=10800

That looks okay - the transition is around midnight, as described.

If, however, you uncomment that last "Rule" line above - which is an exact duplicate of the earlier one - you get:

.../Africa/Cairo  Thu May  9 20:59:59 1957 UT = Thu May  9 22:59:59 1957 EET isdst=0 gmtoff=7200
.../Africa/Cairo  Thu May  9 21:00:00 1957 UT = Fri May 10 00:00:00 1957 EET DST isdst=1 gmtoff=10800

Now the transition is one hour earlier.

As it happens, this duplicate rule doesn't make any difference to Noda Time - it still emits the first output.

I strongly suspect that I shouldn't care about this - that situations with duplicate rules should be deemed out of scope for any implementation. However, if anyone can think of any good justification why an implementation should behave like zic in this case, I'd be really interested to hear it.

(I'm not asking for zic to change here. It already emits a warning because the rule is defined in multiple files, and I think that's good enough.)

Jon

Jon Skeet | 19 Jul 09:12 2015
Picon

[tz] Type values in rules

Hi folks,

It wasn't until last night that I first saw a non "-" entry for a type line - Australia/Adelaide had rules of

Rule    AS      1990    1994    even    Mar     Sun>=18 2:00s   0       -
Rule    AS      1990    1994    odd     Mar     Sun>=1  2:00s   0       -

until release 2000f.

Now in Noda Time I could probably support non-infinite rules with a fixed set of types (hopefully just odd and even), but it would be a bit of work. If type values are effectively obsolete, I may not bother.

So, is it just coincidence that there have been no uses of the Type field in the released data since 2000f, or is this effectively policy now? (I can understand keeping the functionality for private usage, where others may use zic with their own data sets, but for Noda Time I'm not worried about that.

Jon

Tim Parenti | 18 Jul 23:47 2015

[tz] No leap second on 2015-12-31.

Per IERS Bulletin C50 (2015-07-07), no leap second will be observed on 
2015-12-31.  This patch updates leap-seconds.list from NIST.

-- 
Tim Parenti

From 970dfd380307e5a6712b242a598342ca41d71cc7 Mon Sep 17 00:00:00 2001
From: Tim Parenti <tim <at> timtimeonline.com>
Date: Sat, 18 Jul 2015 17:31:55 -0400
Subject: No leap second on 2015-12-31.

* leap-seconds.list: Per IERS Bulletin C50 (2015-07-07), no leap second
on 2015-12-31.  Update file from NIST.
http://datacenter.iers.org/eop/-/somos/5Rgv/getTX/16/bulletinc-050.txt
---
 leap-seconds.list | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
 mode change 100755 => 100644 leap-seconds.list

diff --git a/leap-seconds.list b/leap-seconds.list
old mode 100755
new mode 100644
index 5bac01b..0a0bacb
--- a/leap-seconds.list
+++ b/leap-seconds.list
 <at>  <at>  -199,10 +199,10  <at>  <at> 
 #	current -- the update time stamp, the data and the name of the file
 #	will not change.
 #
-#	Updated through IERS Bulletin C49
-#	File expires on:  28 December 2015
+#	Updated through IERS Bulletin C50
+#	File expires on:  28 June 2016
 #
-# <at> 	3660249600
+# <at> 	3676060800
 #
 2272060800	10	# 1 Jan 1972
 2287785600	11	# 1 Jul 1972
 <at>  <at>  -246,4 +246,4  <at>  <at> 
 #	the hash line is also ignored in the
 #	computation.
 #
-#h	45e70fa7 a9df2033 f4a49ab0 ec648273 7b6c22c
+#h	3d037453 3acade76 570bd8f8 be2b8bc9 55ec6fe8
--

-- 
2.1.4


Gmane