- tz - lists.iana.org

[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

Why 2021b needed to be issued
by Paul Eggert Sept. 28, 2021

Sept. 28, 2021

Since 2013 I've been patching tzdb by replacing Zones with Links when Links suffice according to the guidelines. These patches have not affected timestamps after 1970. I've been doing this gradually. The changes have worked without significant incident, partly because end users generally don't care about pre-1970 timestamps, and partly because the few users who do care (astrologers, mostly) know or should know that the pre-1970 Zone data entries are often wrong and even when right are typically grossly inadequate for realistic use outside the named location - this is partly why any focus on pre-1970 is out of scope for tzdb. Preparing all these patches has been a big enough job that I've been doing it gradually since I have limited time. This process was discussed on the list before it began, and although there was some objection, a consensus to move towards these goals was reached at the time. Most of this job was done before 2021a came out. The main difference in this round of patches, is that I had aimed to complete the job, in response to a user query raising equity concerns in 2021a. It is clear that the 2021a setup was not sustainable in the long term, if equity is a goal. Completing the job generated larger patches than usual, and the patches' size triggered concern that they held too many changes all at once. Also, the patches' effects on pre-1970 timestamps in (for example) Norway and Sweden have triggered concerns, much more so than similar changes made (for example) to Angola and Congo in tzdb 2014g. My own view is that we've done this before, many times, it hasn't been a problem in practice, and it's way past time to address the equity concerns as they have a good chance to really bite this project and its repackagers in the future. It's a bad look for us that so much concern about Norway and Sweden has appeared on this mailing list, even though hardly anybody seems to have cared about Angola and Congo. It'll be an even worse look if we ignore this issue weeks, months or even years after it's been made clear to us. I wrote, tested and published several concrete suggestions addressing the fairness problem. In the months since May when the fairness problem was discovered and objections to my proposed fixes were raised, no other concrete fix addressing both of these concerns has been implemented or tested, and all other suggestions made so far would have required significant work, if they would have worked at all, or would have caused more data churn than what I proposed. I realize that there are valid concerns about installing too many of these patches at once, so 2021b affects only nine Zones instead of the thirty-odd Zones in my May proposal. The idea is to do further patch sets in not-too-distant-future releases, so that the job can finally be finished. I also recognize that there are other forms of equity and fairness that should be considered, perhaps along with alternative technical solutions to the problems these patches address. With all this in mind, issuing 2021b now is a significant step toward equity in tzdb. It will let us say that we are moving toward a fair process, and will give us the opportunity and motivation to improve on that process and to address and balance the various other concerns that have recently appeared on the mailing list.

3 3

Preparing to fork tzdb
by Stephen Colebourne Sept. 27, 2021

Sept. 27, 2021

Hi all, As most of you probably know, there is a dispute about the tzdb maintainer's recent changes to merge large numbers of time-zones [1][2]. These have the effect of wiping out historic time-zone information on many locations where the data has been in tzdb for many years. It appears that there is soon to be a new release of tzdb containing these changes. In my opinion, the correct behaviour of the tzdb maintainer would be to revert the controversial changes before doing a release. In the event that the tzdb maintainer does not revert, consideration must be given to forking the project. The purpose of the fork would initially be to maintain the tzdb data set as it was prior to the dispute. This would then be released in parallel to the original tzdb to ensure that downstream projects do not each do their own thing (ie. to minimize incompatibilities downstream). Is there support for a fork? Is anyone willing to help out? Is any other group willing to sponsor tzdb (eg. CLDR or Red Hat)? Please reply to this thread with an indication of support and/or help. thanks Stephen Colebourne [1] https://mm.icann.org/pipermail/tz/2021-June/thread.html [2] https://mm.icann.org/pipermail/tz/2021-September/030372.html

31 151