Terminology mismatch in tzcode file format manpage / header
The file format is described with these fields: .I tzh_ttisgmtcnt The number of UTC/local indicators stored in the file. .I tzh_ttisgmtcnt UTC/local indicators, each stored as a one-byte value; they tell whether the transition times associated with local time types were specified as UTC or local time, and are used when a time zone file is used in handling POSIX-style time zone environment variables. A number of variables in localtime.c, tzfile.h, and zic.c dealing with these fields have variations of this "isgmt" substring. This presents a naming conflict because technically GMT and UTC are two different things. I find the inconsistent naming creeping into functions which deal with the file format. I would like to prevent variations of the string "GMT" from winding up in API names since the definition of the field refers to UTC. I propose wholesale replacing of the "isgmt" substring in tzcode files with "isutc" so that the file format fields are named consistently with their definition. If absolutely necessary, a #define can be used in tzfile.h so that code referencing tzh_ttisgmtcnt will still compile. -Andrew
On Thu 2012-05-17T18:47:14 -0400, Andrew Paprocki hath writ:
This presents a naming conflict because technically GMT and UTC are two different things. I find the inconsistent naming creeping into functions which deal with the file format. I would like to prevent variations of the string "GMT" from winding up in API names since the definition of the field refers to UTC.
I propose wholesale replacing of the "isgmt" substring in tzcode files with "isutc" so that the file format fields are named consistently with their definition. If absolutely necessary, a #define can be used in tzfile.h so that code referencing tzh_ttisgmtcnt will still compile.
For this particular nomenclature issue the ITU-R Radiocommunication Assembly and the World Radio Conference failed to achieve consensus at their meetings earlier this year. Their result is the text Resolution 653 (WRC-12) which has become WRC-15 Agenda Item 1.14 as seen here http://www.itu.int/ITU-R/index.asp?category=study-groups&rlink=rcpm-wrc-15-studies&lang=en#{8259A74D-6541-475F-846C-5255C5EA3FCD} Given the unclear outcome of the ITU-R process I recommend stability rather than change for this issue, at least until the outcomes from RA-15 and WRC-15 are known. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On Thu, May 17, 2012 at 7:10 PM, Steve Allen <sla@ucolick.org> wrote:
Given the unclear outcome of the ITU-R process I recommend stability rather than change for this issue, at least until the outcomes from RA-15 and WRC-15 are known.
I was under the impression WRC-12 was discussing a proposal to eliminate leap seconds, redefining UTC, and that is what was tabled to the WRC-15 agenda. Potential changes to the UTC standard do not seem relevant when discussing the use of both "GMT" and "UTC" in the same definition of a field in the tz file format. Theory states: To represent this data, the world is partitioned into regions whose clocks all agree about time stamps that occur after the somewhat-arbitrary cutoff point of the POSIX Epoch (1970-01-01 00:00:00 UTC). For each such region, the database records all known clock transitions, and labels the region with a notable location. This implies to me that "utc" should be used in the field name, to match the existing definition next to it which states "UTC". -Andrew
On Thu 2012-05-17T21:31:10 -0400, Andrew Paprocki hath writ:
I was under the impression WRC-12 was discussing a proposal to eliminate leap seconds, redefining UTC, and that is what was tabled to the WRC-15 agenda.
During the past 10 years the proposals have been to change the characteristics of the broadcast time scale while retaining the name UTC.
Potential changes to the UTC standard do not seem relevant when discussing the use of both "GMT" and "UTC" in the same definition of a field in the tz file format.
The text of agenda item 1.14 is 1.14 to consider the feasibility of achieving a continuous reference time-scale, whether by the modification of coordinated universal time (UTC) or some other method, and take appropriate action, in accordance with Resolution 653 [COM6/20] (WRC-12) This wording invites the possibility of changing both the characteristics and the name of the internationally-approved broadcast time scale if that is the expedient means of achieving the change needed for technical purposes. It seems imprudent to change the name of the functions in the tzcode if in three years the name of the broadcast time scale might change to something other than UTC.
This implies to me that "utc" should be used in the field name, to match the existing definition next to it which states "UTC".
Except that the implementation of zoneinfo is based on the POSIX notion of UTC, and that is incongruent with the ITU-R notion of UTC. This is similar to other aspects of zoneinfo where authority and practice differ due to Byzantine bureaucratic processes run by hot-headed folks with entrenched but opposing positions. No action taken by the tz list can solve the fundamental problem nor avoid confusion in actual practice. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
On May 17, 2012, at 6:52 PM, Steve Allen wrote:
Except that the implementation of zoneinfo is based on the POSIX notion of UTC, and that is incongruent with the ITU-R notion of UTC.
So what's the POSIX notion of UTC? In the 2010 version of the Single UNIX Specification (that being the latest version of POSIX, unless www.unix.org isn't showing me the latest version), chapter 3 "Definitions" of the Base Definitions section says 3.150 Epoch The time zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time (UTC). and section 4 "General Concepts" of the Base Definitions section says 4.15 Seconds Since the Epoch A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, andtm_year are all integer types: tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. Note: The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient. That doesn't handle certain UTC names (such as those where "tm_sec" is 60) in a fashion that always gives two different UTC names different seconds-since-the-Epoch values; is that what you're referring to? (Hey, at least they say "approximates", rather than claiming that it's actually a count of seconds that have elapsed since the Epoch.)
On Thu, May 17, 2012 at 9:52 PM, Steve Allen <sla@ucolick.org> wrote:
It seems imprudent to change the name of the functions in the tzcode if in three years the name of the broadcast time scale might change to something other than UTC.
Except that the implementation of zoneinfo is based on the POSIX notion of UTC, and that is incongruent with the ITU-R notion of UTC.
As you've pointed out, zoneinfo is based on the POSIX Epoch definition, so I don't see why ITU-R proceedings have a bearing on what I was proposing. There are no "functions" in tzcode which would change name. The only thing that would change name is the struct member tzh_ttisgmtcnt, which represents "UTC/local indicators, each stored as a one-byte value; they tell whether the transition times associated with local time types were specified as UTC or local time". As ado pointed out in 2007: http://mm.icann.org/pipermail/tz/2007-December/014729.html "This is indeed historical; the tzh_tisgmtcnt and tzh_ttisstdcnt header fields (and associated variables) were introduced in 1995 to allow European time zones to be used as time zone templates, and the software had to be set up to handle older files from which the information was absent (and in which the header fields were zero)." These values have been identical for ages, so I'm suggesting just naming the field to match its definition as an easy win to avoid confusion. It does not actually have any bearing on the interpretation of the data. -Andrew
On Thu, May 17, 2012 at 6:47 PM, Andrew Paprocki <andrew@ishiboo.com> wrote:
.I tzh_ttisgmtcnt The number of UTC/local indicators stored in the file.
It is worth noting that this definition changed from saying "GMT/local" to "UTC/local" in tzcode1997i. Paul Eggert posted this patch: http://mm.icann.org/pipermail/tz/1997-December/010044.html "The proposed patch attempts to use the correct terms more consistently." I am just suggesting that the struct name should have been changed at the same time. -Andrew
On Fri, May 18, 2012 at 5:45 AM, Andrew Paprocki <andrew@ishiboo.com> wrote:
It is worth noting that this definition changed from saying "GMT/local" to "UTC/local" in tzcode1997i. Ouch. Did the values change too, or have they been false before?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/
participants (4)
-
Andrew Paprocki -
Guy Harris -
Steve Allen -
Tobias Conradi