- tz - lists.iana.org

Discussion on LWN on the equity controversy
by Sanjeev Gupta Oct. 1, 2021

Oct. 1, 2021

Folks, On Linux Weekly News (which actually is about more than Linux), there is a summary and discussion on the issues raised here. LWN has a very high signal/noise ratio, I find. I have been a paid subscriber for a couple of decades. Here is a link (LWN allows subscribers to generate a link to an article for viewing by non-subscribers, all content s free after a week): https://lwn.net/SubscriberLink/870478/9dcc3764b87edfaf/ Thanks, -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1

Dropping coordinates from zone1970.tab?
by Aurelien Jarno Oct. 1, 2021

Oct. 1, 2021

Hi, With the recent changes, geographically distant locations share the same timezone and the same coordinates in the zone1970.tab file. For instance Antarctica/Syowa is a link to Asia/Riyadh and appear with the same coordinates in the zone1970.tab file, while they are more than 10000 km apart. The zone1970.tab says: "This table is intended as an aid for users, to help them select timezones appropriate for their practical needs". I have the impression that the coordinates in that table do not anymore aid users to select appropriate timezones, so I wonder if they should just get dropped. Regards, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien(a)aurel32.net http://www.aurel32.net

4 16

[PATCH] Formatting of NEWS file is inconsistent in 2021b
by Paul Ganssle Sept. 30, 2021

Sept. 30, 2021

All previous entries in NEWS have a format of headings following nested levels of indentation — the release is unindented, then subheadings with a 2-space indentation, then the contents of each subhead are blocks indented with 2 spaces. In the 2021b release, there is some commentary about the release that isn't indented to the level of the "Briefly" sub-block, but also doesn't have its own heading. I think it would be preferable to put this note under a heading rather than as free-floating content at the level of other subheads. I've attached a patch to move the note into the "Briefly" subheading, though it could also be a separate heading like "Note about the 2021b release" or something. I don't really expect this format to be guaranteed or anything, but for selfish reasons I liked the consistency of the previous format since it makes it much easier for me to parse the NEWS file for repackaging in the Python tzdata format. Obviously I do not consider this any sort of contract or required interface, but since it seems unlikely that accepting this patch would increase your maintenance burden and it will decrease my maintenance burden by a decent amount in the future, I'm hoping you wont' mind accepting this patch (or a similar one). Thanks! Paul

2 1

(no subject)
by Cool Gab19 Sept. 30, 2021

Sept. 30, 2021

I knew that we do already have a time zone for Philippines, Asia/Manila called "Philippine Standard Time" with an offset of UTC+8:00 but the other one I was requesting is for the body of water surrounded inside the mainland such as the Ocean or Sea. I'm proposing to add UTC/GMT+8:15 to your database We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,and if there's an specific location it's Asia/Philippines with different abbreviation "Philippine Pacific Time" with offset of UTC+8;15and will be used inside Philippine sea (not in mainland)

2 1

something wrong with 2021b zdump
by 大山俊成 Sept. 30, 2021

Sept. 30, 2021

I compared 2021b with 2021a. The result is following. I don't understand the meaning for line 3-5,20-22 of 2021b result. Is it correct ? *** tzdb-2021b $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -67768040609740801 = NULL Pacific/Honolulu Thu Jan 1 00:00:00 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:25 -2147481748 UT = NULL Pacific/Honolulu Thu Jan 1 10:31:26 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 13:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191676800 = Wed Dec 31 14:00:00 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712799 = Wed Dec 31 23:59:59 2147485547 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 67768036191712800 = NULL Pacific/Honolulu 9223372036854775807 = NULL *** tzdb-2021a $ ./zdump -v Pacific/Honolulu Pacific/Honolulu -9223372036854775808 = NULL Pacific/Honolulu -9223372036854689408 = NULL Pacific/Honolulu Mon Jan 13 22:31:25 1896 UT = Mon Jan 13 11:59:59 1896 LMT isdst=0 gmtoff=-37886 Pacific/Honolulu Mon Jan 13 22:31:26 1896 UT = Mon Jan 13 12:01:26 1896 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:29:59 1933 UT = Sun Apr 30 01:59:59 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Apr 30 12:30:00 1933 UT = Sun Apr 30 03:00:00 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:29:59 1933 UT = Sun May 21 11:59:59 1933 HDT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun May 21 21:30:00 1933 UT = Sun May 21 11:00:00 1933 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:29:59 1942 UT = Mon Feb 9 01:59:59 1942 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Mon Feb 9 12:30:00 1942 UT = Mon Feb 9 03:00:00 1942 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 22:59:59 1945 UT = Tue Aug 14 13:29:59 1945 HWT isdst=1 gmtoff=-34200 Pacific/Honolulu Tue Aug 14 23:00:00 1945 UT = Tue Aug 14 13:30:00 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:29:59 1945 UT = Sun Sep 30 01:59:59 1945 HPT isdst=1 gmtoff=-34200 Pacific/Honolulu Sun Sep 30 11:30:00 1945 UT = Sun Sep 30 01:00:00 1945 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:29:59 1947 UT = Sun Jun 8 01:59:59 1947 HST isdst=0 gmtoff=-37800 Pacific/Honolulu Sun Jun 8 12:30:00 1947 UT = Sun Jun 8 02:30:00 1947 HST isdst=0 gmtoff=-36000 Pacific/Honolulu 9223372036854689407 = NULL Pacific/Honolulu 9223372036854775807 = NULL ---- Toshinari Ohyama

2 2

Merged 1970+ time zones should always return -1 pre-1970
by Brian Inglis Sept. 29, 2021

Sept. 29, 2021

I think for all zones with data merged prior to 1970, the data and API should always return *-1* for all times prior to 1970-01-01 00:00:00Z, as anything else is inaccurate or a kludge. Arbitrary disposition of any valid historical data is itself really political, for ease of administration, not really technical. I firmly believe that no decision on the list has ever been made on a basis of in-/equity or un-/fairness, as those would be political decisions, and we have bent over backwards for years to avoid any such appearance never mind actuality, devoting probably the majority of the volume of posts and the majority of the volume of words to such discussions. I have always taken the position that any churn not necessitated by changes on the ground (or government offices) is detrimental to the project and the database, and places a massive burden on downstreams who make good use of that data, including the CLDR and ICU projects, astronomy and astrology applications, all facets of the transportation industry, the databases they maintain, and the storage of what was the truth at a previous point in time, and future application uses of that previously stored data. Any such churn should be mediated by the request the list makes of time zone decision makers: to provide adequate notice of such changes, at least six months, preferably longer. I can only believe that the adminstrators of this database are under some form of political pressure (perhaps /only/ "vitriol in private email", which appears to be nearing the norm in certain arenas) to dispose of some data to achieve some misguided form of "equity" and "fairness", in response to some misguided perception of "inequity" and "unfairness" that is not apparent to members of this mailing list, and from the reactions, nor does it appear to have been adequately or clearly expressed in a form that members of this list can readily comprehend, nor is it clearly exactly when these political terms entered the discussion, nor what business they have being in it. As in any project where decisions are questionable, it is necessary to back off making any! The proposers of drastic changes need to enunciate clearly: * exactly what technical problem they perceive, and why it appears to be a problem; * some alternative options for technical solutions and/or approaches to address the technical problem; * how each alternative option for technical solutions and/or approaches to address the problem will satisfy the majority of needs of the majority of the stakeholders, and impacts on those unsatisfied; * why they think the option they propose to adopt is the best and most comprehensive solution to address the problem, and satisfies the most needs of the most stakeholders. This is standard practice in most commercial projects. It is often used when stakeholders can not quickly make a decision, decide on policy, or easily change policy. It allows development to proceed in parallel on all the offered options. When stakeholders finally decide or act, perhaps months along the timeframe nearing release, the selected option can be preferentially enabled, possibly with only minor tweaks or just data changes, and quickly regression tested to ensure the effect is precisely as desired. Of course, the best decision to satisfy the most needs of the most stakeholders is often the decision to just say "NO !" ;^> -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

9 15

Using the tzdb: What's actually changed
by Watson Ladd Sept. 29, 2021

Sept. 29, 2021

Dear all, I see lots and lots of people who seem to be running applications that care about pre 1970 timestamps and don't use backzones, or seem to ignore links. Well, if you ignore links you deserve what you get: it's been documented that zones may become links. The size of tzdb has already caused problems for some embedded devices. Post-1970 correctness only strikes me as very reasonable. Applications that need more should use backzones, and this has been true for years. If you care about the truth of what time something happened, and it was recorded in local time, and the zone that it was in might need to get split in the future, and that split could change when the time was or other times you care about then the database isn't your problem, reality is. I see a lot of complaints, and very few details about the applications affected. Which makes me skeptical they actually exist. Remember, you're only affected if you deal with pre-1970 timestamps. Sincerely, Watson -- Astra mortemque praestare gradatim

4 5

[PATCH] Port better to >64-bit platforms
by Paul Eggert Sept. 29, 2021

Sept. 29, 2021

* zic.c (limitrange, writezone): Use max_time instead of ZIC_MAX when dealing with timestamps that would go into the TZif file. The distinction matters only on very unusual platforms where int_fast64_t is wider than 64 bits. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index c6feb8b..224cc22 100644 --- a/zic.c +++ b/zic.c @@ -1990,7 +1990,7 @@ limitrange(struct timerange r, bool locut, zic_t lo, zic_t hi, /* Omit ordinary and leap second transitions greater than HI + 1. */ - if (hi < ZIC_MAX) { + if (hi < max_time) { while (0 < r.count && hi + 1 < ats[r.base + r.count - 1]) r.count--; while (0 < r.leapcount && hi + 1 < trans[r.leapbase + r.leapcount - 1]) @@ -2205,7 +2205,7 @@ writezone(const char *const name, const char *const string, char version, error(_("too many transition times")); thistimelim = thistimei + thistimecnt; - if (thistimecnt && hi_time < ZIC_MAX + if (thistimecnt && hi_time < max_time && ats[thistimelim - 1] == hi_time + 1) hicut = false; memset(omittype, true, typecnt); -- 2.30.2

1 0

Request
by Cool Gab19 Sept. 29, 2021

Sept. 29, 2021

I'm proposing to add UTC/GMT+8:15? We do have an 8:30 and 8:45 zone. Why not 8:15? Plus,the GMT+8:15 if ever will be named as Anywhere on Southeast Asia Time (ASAT) (Asia/Southeast) a very usable time zone in southeast asian countries specially in zone 7 and 8.

2 1

Re: [tz] [EXTERNAL] [tz-announce] 2021b release of tz code and data available
by Paul Eggert Sept. 28, 2021

Sept. 28, 2021

On 9/28/21 5:57 AM, crdrequest(a)ups.com wrote: > I was informed that the start Jordan now starts DST on February's last FRIDAY.....NOT THURSDAY. My guess is that you're OK because your informant referred to 00:00 on February's last Friday, which in 2022 is equivalent to what we have in tzdb 2021b (namely, 24:00 on February's last Thursday). The distinction between the two rules matters only in one year out of seven, the first such year being 2024 when February ends on a Thursday. Our source for the 24:00-on-last-Thursday rule is here (in Arabic): https://petra.gov.jo/Include/InnerPage.jsp?ID=189969&lang=ar&name=news

1 0