- tz - lists.iana.org

The link-name, America/Virgin, is linked to two zones in 'backzone'
by Yan-Jie Wang Nov. 12, 2021

Nov. 12, 2021

A link-name (the second column of the Link line) in a file should be unique. However, 'America/Virgin' is linked to two zones (America/Port_of_Spain and America/St_Thomas) in 'backzone'. The error is in the latest commit as well as in the archive tzdata2021e.tar.gz. The link to the file: https://github.com/eggert/tz/blob/6c15079/backzone Yan-Jie Wang

2 1

Re: [tz] What are the interfaces to the TZDB?
by Brian Park Nov. 10, 2021

Nov. 10, 2021

(Replying back to the list with permission) On Tue, Nov 9, 2021 at 11:45 AM Eliot Lear <lear(a)lear.ch> wrote: > On 09.11.21 20:38, Brian Park wrote: > > Is the TZDB project intended to support only POSIX systems? > > It's a fair question. Before we say, “no”, I would like to understand > what sort systems use the database that themselves are *NOT* POSIX > compliant. But also, as Paul pointed out, the binary format itself is > standardized at the IETF, the sponsor of this shindig. > > We could go up the stack, but before we do so, we should be clear on our > reasons as to why we are doing so. And so when you say: > > My downstream usage does not have a file system, or even an operating > system. For me, the API into the TZDB project are the raw files, but I > understand that my usage is unusual. > > Would you mind being a bit more specific? Are you printing a book? ;-) > Not that primitive... My libraries run on bare-metal, embedded microcontrollers, with no operating system. My first version is in C++, supporting all Zones and Links in about 36kB of flash (8-bit controllers) to 44kB of flash (32-bit controllers), without using 64-bit integers. I have another version in Python that I hope to convert to MicroPython soon. I'm hoping to write another version in Go lang, which will be converted into TinyGo. Brian

2 1

Re: [tz] Pre-1970 data
by dpatte Nov. 5, 2021

Nov. 5, 2021

I was be contributing a longer message on this whole subject within a few days, but I want to state upfront that country/city is insufficient in many countries for a fully expandable location database.Off the top of my head, I can think of three different Richmonds in Canada. One in Quebec, one in Ontario, and one in BC. I know there are many Springfields in many USA states, and let's not even talk about the potential USA/Columbus.The key of a database should be unique and recognizable. For many countries, multiple levels of government are the only way to properly differentiate cities.Canada/British_Columbia/Richmond would be more appropriate.This allows the pre-1970 db to be both infinitely expandable, as well as user friendly to the point of being fully obvious to all users.Sent from my Galaxy -------- Original message --------From: Brian Park via tz <tz(a)iana.org> Date: 2021-11-05 11:27 (GMT-05:00) To: Philip Paeps <philip(a)trouble.is> Cc: Stephen Colebourne <scolebourne(a)joda.org>, Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Pre-1970 data On Thu, Nov 4, 2021 at 10:11 PM Philip Paeps <philip(a)trouble.is> wrote:On 2021-11-05 12:17:34 (+0800), Brian Park via tz wrote: > I get the impression that this debate is caused by the existence of 2 > different schools of thought: [...] > > I want to suggest that it may be possible for these 2 views to > coexist. They de facto coexist right now. The overwhelming majority of the data are descriptive. Only recent efforts have made some of the post-1970 data appear more prescriptive.They coexist in an ad hoc manner right now, and that seems to be one of the causes for the contention. I am suggesting that we formalize the separation, so that both groups are happier. > We > could create a new file, e.g. call it 'countryzone', which contains a > set > of Links organized in a hierarchical tree by country, pointing to the > Core > zones. I strongly believe we should continue to carefully avoid attempting to group data by country. [I would even avoid using the word "country" wherever possible.]Can you explain why? Because it will cause arguments about disputed places? I think only a small minority of places around the world are disputed. By separating these ISO-country timezones into a 'countryzone' file, perhaps we can confine the debate into a smaller section of the TZDB. We could create duplicate entries (i.e. Country1/City, Country2/City), or create a pseudo-country called "Disputed" (i.e. Disputed/City). The point is, we can create policies that govern these disputed regions.Could we move 'countryzone' into a separate project? Probably, but some amount of initial coordination and refactoring would be required to resolve conflicting zone identifiers.Overall, I feel like the TZDB data should lean a bit more towards matching how end-users think about timezones in the real world (Prescriptive), and lean slightly less on treating timezones as a clustering problem (Descriptive). But I can see pros and cons of both approaches. Which is why I am suggesting ways to make the 2 approaches interoperate better. > For the pre-1970 data, it is my understanding that the 'backzone' file > contains Zone records which should replace ONLY the LinkMerged records > found in the other files. I propose that all LinkMerged records be > extracted into a separate file (let's call it 'mergedzone') so that > there > is a clear symmetry between 'backzone' and 'mergedzone', which allows > them > to be substituted for each other. The dependency diagram looks > something > like this: As I've suggested before in another thread, I think we should consider undoing the split into backzone. I really liked Stephen's phrasing earlier in this thread: acceptably accurate, not outrageously wrong. We started moving data to backzone to limit the scope of 'active' maintenance to post-1970 data. That artificial split led us towards a more prescriptive worldview. It seems clear that prescriptive simply does not work for a real world with people on it.I think Paul Eggert has made it clear that he does not want to maintain this data. My proposed refactoring of this info into the 'backzone' / 'mergedzone' pair makes it easy for downstream libraries to add back the 'backzone' data if they want. The 'make PACKRATDATA=backzone' hack does not help downstream libraries which do not use TZif or the Makefile. > If there is any chance that this will result in being able to type > "Canada/Toronto" instead of "America/Toronto", that would resolve an > annoyance that has lasted some 30-35 years. In this context, America refers to the landmass, not to the political entity occupying a large chunk of it. [Canada/Eastern etc moved to backward around 1993, as far as I can tell.]Virtual no one in the world thinks of "America" as referring to all of "North America" and "South America".Brian

2 1

Ref: Tz on social media
by nadir altinbas Nov. 4, 2021

Nov. 4, 2021

is it possible to add 'news' from TZ Coordiation web site share button to social media such as; Linkedin,FaceBook(meta),Instagram,Twitteretc.... There may be occur an anouncment to publicize for sharing via social media? Nadir Altinbas Estanbul /TR, 2021 Nov,2 nadiraltinbas(a)yahoo.com n.altinbas

2 2

event of interest: Future of Europe debates – The end of DST: how can it be placed back to the European agenda?
by BASTIAN Michelle Oct. 28, 2021

Oct. 28, 2021

Hi all, I was just at events for the Barcelona Time Use initiative time use week 2021 and the panel on changing DST in Europe was very interesting and I thought some of you might want to take a look. It is free to sign up and you can access recordings of all the events including the one on time zones/DST. Description and link below. Loved that there was lots of talk about there being no problem having many more time zones in Europe as ‘our computers handle all of that for us now’. https://timeuseweek.beplanet.tv/en/ Future of Europe debates – The end of DST: how can it be placed back to the European agenda? In 2019, the European Parliament agreed to end the biannual clock change. Nevertheless, the Member States have not been able to achieve an agreement on which time zone has to be adopted. This debate explores how can we place back the debate on the European and Member States agenda. Representative of European Parliament Pending to confirm Maria Nikolopoulou European social and economic council Ticia Luengo International Association for Natural Time Till Roenneberg World Federation of Societies for Chronobiology Best, Michelle. --- Dr Michelle Bastian Mid-Career Fellow, Independent Social Research Foundation (Project info<https://www.isrf.org/fellows-projects/michelle-bastian/>) Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

3 2

Re: [tz] tzcode2021e: uninitialized variable in localtime.c
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

On 10/22/21 07:49, Christos Zoulas wrote: > My linter reports "prevcorr" is uninitialized in the if statement > below the comment that starts "To avoid other botches". Thanks for mentioning that. This prompted me to find an obscure bug in localtime that would cause it to access an uninitialized local variable (which is undefined behavior) in cases involving 32-bit time_t code reading malformed 64-bit data. I installed the attached patch to fix the bug, and I hope this also pacifies your linter.

2 1

[PROPOSED] Be more generous when dealing with v1 data
by Paul Eggert Oct. 27, 2021

Oct. 27, 2021

* NEWS: Mention this. * localtime.c (tzloadbody): In version 2 and later files, do not attempt to validate the version 1 header and data block; instead, ignore them except for the purpose of skipping over them, as per a recommendation in RFC 8536 section 4. Also, when the TZif file is version 1 and we break out near the end of the loop, do so only after altering nread and memmoving any later data; this avoids having later code attempt to parse the version 1 header as if it were a TZ string. --- NEWS | 6 +++++ localtime.c | 71 +++++++++++++++++++++++++++++++---------------------- 2 files changed, 47 insertions(+), 30 deletions(-) diff --git a/NEWS b/NEWS index d4a9823..0f684f7 100644 --- a/NEWS +++ b/NEWS @@ -14,6 +14,12 @@ Unreleased, experimental changes Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) + When reading a version 2 or later TZif file, the TZif reader now + validates the version 1 header and data block only enough to skip + over them, as recommended by RFC 8536 section 4. Also, the TZif + reader no longer mistakenly attempts to parse a version 1 TZIf + file header as a TZ string. + Release 2021e - 2021-10-21 18:41:00 -0700 diff --git a/localtime.c b/localtime.c index 6d736b2..39ef6e3 100644 --- a/localtime.c +++ b/localtime.c @@ -434,35 +434,45 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (close(fid) < 0) return errno; for (stored = 4; stored <= 8; stored *= 2) { - int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); - int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); - int_fast64_t prevtr = -1; - int_fast32_t prevcorr; - int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); - int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); - int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); - int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); - char const *p = up->buf + tzheadsize; - /* Although tzfile(5) currently requires typecnt to be nonzero, - support future formats that may allow zero typecnt - in files that have a TZ string and no transitions. */ - if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS - && 0 <= typecnt && typecnt < TZ_MAX_TYPES - && 0 <= timecnt && timecnt < TZ_MAX_TIMES - && 0 <= charcnt && charcnt < TZ_MAX_CHARS - && (ttisstdcnt == typecnt || ttisstdcnt == 0) - && (ttisutcnt == typecnt || ttisutcnt == 0))) - return EINVAL; - if (nread - < (tzheadsize /* struct tzhead */ - + timecnt * stored /* ats */ + char version = up->tzhead.tzh_version[0]; + bool skip_datablock = stored == 4 && version; + int_fast32_t datablock_size; + int_fast32_t ttisstdcnt = detzcode(up->tzhead.tzh_ttisstdcnt); + int_fast32_t ttisutcnt = detzcode(up->tzhead.tzh_ttisutcnt); + int_fast64_t prevtr = -1; + int_fast32_t prevcorr; + int_fast32_t leapcnt = detzcode(up->tzhead.tzh_leapcnt); + int_fast32_t timecnt = detzcode(up->tzhead.tzh_timecnt); + int_fast32_t typecnt = detzcode(up->tzhead.tzh_typecnt); + int_fast32_t charcnt = detzcode(up->tzhead.tzh_charcnt); + char const *p = up->buf + tzheadsize; + /* Although tzfile(5) currently requires typecnt to be nonzero, + support future formats that may allow zero typecnt + in files that have a TZ string and no transitions. */ + if (! (0 <= leapcnt && leapcnt < TZ_MAX_LEAPS + && 0 <= typecnt && typecnt < TZ_MAX_TYPES + && 0 <= timecnt && timecnt < TZ_MAX_TIMES + && 0 <= charcnt && charcnt < TZ_MAX_CHARS + && 0 <= ttisstdcnt && ttisstdcnt < TZ_MAX_TYPES + && 0 <= ttisutcnt && ttisutcnt < TZ_MAX_TYPES)) + return EINVAL; + datablock_size + = (timecnt * stored /* ats */ + timecnt /* types */ + typecnt * 6 /* ttinfos */ + charcnt /* chars */ + leapcnt * (stored + 4) /* lsinfos */ + ttisstdcnt /* ttisstds */ - + ttisutcnt)) /* ttisuts */ + + ttisutcnt); /* ttisuts */ + if (nread < tzheadsize + datablock_size) + return EINVAL; + if (skip_datablock) + p += datablock_size; + else { + if (! ((ttisstdcnt == typecnt || ttisstdcnt == 0) + && (ttisutcnt == typecnt || ttisutcnt == 0))) return EINVAL; + sp->leapcnt = leapcnt; sp->timecnt = timecnt; sp->typecnt = typecnt; @@ -578,13 +588,14 @@ tzloadbody(char const *name, struct state *sp, bool doextend, ttisp->tt_ttisut = *p++; } } - /* - ** If this is an old file, we're done. - */ - if (up->tzhead.tzh_version[0] == '\0') - break; - nread -= p - up->buf; - memmove(up->buf, p, nread); + } + + nread -= p - up->buf; + memmove(up->buf, p, nread); + + /* If this is an old file, we're done. */ + if (!version) + break; } if (doextend && nread > 2 && up->buf[0] == '\n' && up->buf[nread - 1] == '\n' && -- 2.31.1

1 0

Extra transition type is generated by zic with -r specified
by Almaz Mingaleev Oct. 26, 2021

Oct. 26, 2021

I’ve tried to generate a TZif file with transitions up to 1 Jan 2100 using zic with -r and “-b fat”. However, an extra transition type is generated for many (all?) time zones. That type’s UTC offset is zero and it is used only for the last transition in the 64-bit section. What I did: mkdir /tmp/zic cd /tmp/zic git clone https://github.com/eggert/tz.git . make -C . zic make -C . NDATA= rearguard.zi mkdir data ./zic -b fat -r /@4102444800 -d ./data rearguard.zi Below is an investigation for Australia/Lord_Howe (I don’t think choice matters here). I couldn’t find a way to force zdump to print transitions for a given TZif file. Instead, please see human-readable dumps from the TZif from our internal tools immediately below and raw byte information at the bottom if you’d prefer to work with that. These are local time transition types for Australia/Lord_Howe: Types gmtOffset (seconds),isDst,ttisgmt,ttisstd,[gmtOffset ISO],[DST?] 38180,0,,,PT10H36M20S,STD 0,0,,,PT0S,STD <- this is odd 36000,0,,,PT10H,STD 41400,1,,,PT11H30M,DST 37800,0,,,PT10H30M,STD 39600,1,,,PT11H,DST Transitions: transition,type,[UTC time],[Type offset],[Type isDST] … 4063275000,5,2098-10-04T15:30:00Z,PT11H,DST 4078998000,4,2099-04-04T15:00:00Z,PT10H30M,STD 4094724600,5,2099-10-03T15:30:00Z,PT11H,DST 4102444800,1,2100-01-01T00:00:00Z,PT0S,STD <- this is odd So, after the upper bound specified in -r, the transitions say that GMT is used. As I’d expect, the 32-bit transitions are not affected when the upper bound in -r is after 2038. However, with -r /@1634833073 the 32-bit section also has 6 transition types and the last transition sets offset to 0. Is that a bug or is there a reason for such behaviour? Thanks, Almaz Byte manipulations: typecnt is 5 in 32-bit section: xxd -seek 36(4+1+15+4*4) -len 4 data/Australia/Lord_Howe 64-bit section starts at offset 674. timecnt is 0xF0(=240) in 64-bit section: xxd -seek 706(674 + 20 + 3 * 4) -len 4 data/Australia/Lord_Howe typecnt is 6 in 64-bit section: xxd -seek 710(706 + 4) -len 4 data/Australia/Lord_Howe So, 64-bit header has one extra transition type. Let’s check how it is used and what that transition is: 2638 = 674 + 44 + 240 * 8 xxd -seek 2638 -len 240 -c 1 data/Australia/Lord_Howe prints transition types: 00000b38: 05 . 00000b39: 04 . 00000b3a: 05 . 00000b3b: 04 . 00000b3c: 05 . 00000b3d: 01 . Transition type is changing from 4 to 5, but the last one is 1. xxd -seek 2878 -len 36 -c 6 data/Australia/Lord_Howe prints local time type records: 00000b3e: 0000 9524 0004 ...$.. 00000b44: 0000 0000 0000 ...... <- the last transition type 00000b4a: 0000 8ca0 0008 ...... 00000b50: 0000 a1b8 010d ...... 00000b56: 0000 93a8 0013 ...... 00000b5c: 0000 9ab0 0119 ...... Which means that 1st type’s offset is 0 and that the last rule for Lord Howe is actually GMT.

2 4

[PROPOSED] Improve Palestine predictions for 2025 and later
by Paul Eggert Oct. 25, 2021

Oct. 25, 2021

* NEWS: Mention this. * asia (Palestine): Guess Fri>=23, not lastFri, for fallback transitions in the future. Fri>=23 is more consistent with past practice than lastFri. The first differing prediction is a fallback on 2025-10-24, not 2025-10-31. --- NEWS | 10 ++++++++++ asia | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index a7aa269..d83e01c 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,15 @@ News for the tz database +Unreleased, experimental changes + + Changes to future timestamps + + Predict Palestine fallbacks to be the first Friday on or after + October 23, not October's last Friday, to be more consistent with + past practice. The first differing prediction is a fallback on + 2025-10-24, not 2025-10-31. + + Release 2021e - 2021-10-21 18:41:00 -0700 Changes to future timestamps diff --git a/asia b/asia index dd228e5..6d6b1de 100644 --- a/asia +++ b/asia @@ -3445,7 +3445,7 @@ Rule Palestine 2019 only - Mar 29 0:00 1:00 S Rule Palestine 2019 only - Oct Sat>=24 0:00 0 - Rule Palestine 2020 max - Mar Sat>=24 0:00 1:00 S Rule Palestine 2020 only - Oct 24 1:00 0 - -Rule Palestine 2021 max - Oct lastFri 1:00 0 - +Rule Palestine 2021 max - Oct Fri>=23 1:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Asia/Gaza 2:17:52 - LMT 1900 Oct -- 2.31.1

3 3

Wrong name of timezone
by Igor Melnyk Oct. 25, 2021

Oct. 25, 2021

Hello! There is *Europe**/Kiev* timezone related to Ukraine. But Ukraine has the Ukrainian language and *Kiev* is in russian language. The correct name of the capital city of Ukraine is *Kyiv.* It must be changed. I know that it's not easy to do that but you must have some way to do that. For example, rename *Europe/Kiev* to *Europe/Kyiv* and make *Europe/Kiev* to be a temporary alias or link to *Europe/Kyiv.* What do you think about it? Best regards, Igor Melnyk.

1 0