- tz - lists.iana.org

[YBA] TLD make using mawk causes malloc failure
by Jonathan Ben Avraham Jan. 19, 2022

Jan. 19, 2022

Dear colleagues, I noticed that on all tz versions up to 2021e running make in the top-level directory results in a malloc failure on Debian 10 which uses the mawk alternate for awk: cc -DTZDIR='"/usr/share/zoneinfo"' -c -o difftime.o difftime.c rm -f libtz.a ar -rc libtz.a localtime.o asctime.o difftime.o strftime.o : libtz.a awk -v DATAFORM=`expr main.zi : '$.*$.zi'` -f ziguard.awk \ africa antarctica asia australasia europe northamerica southamerica etcetera factory backward >main.zi.out malloc(): unsorted double linked list corrupted Aborted make: *** [Makefile:612: main.zi] Error 134 This can be corrected by installing gawk and running update-alternatives --config awk to select gawk as the awk alternate. I verified that the make completes without error using either GNU Awk 4.1.4, or GNU Awk 4.2.1. I did not see any warning about this in any of the NEW or README files, which is unfortunate as I spent several hours of my employers time understanding the problem and I suspect that others have seen this already. I suggest adding an INSTALL readme to say which environments are known to work and if there are specific know issues such as mawk. Best regards, - yba -- 9590 8E58 D30D 1660 C349 673D B205 4FC4 B8F5 B7F9 ~. .~ Tk Open Systems =}-------- Jonathan Ben-Avraham ("yba") ----------ooO--U--Ooo------------{= mailto:yba@tkos.co.il tel:+972.52.486.3386 http://tkos.co.il skype:benavrhm

3 3

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Doug Ewell Jan. 15, 2022

Jan. 15, 2022

heba.hamad at mtit.gov.ps wrote: > We would like to inform you that The State of Palestine has adopted > the first part of the specification for its time zone. and linked a document which states in part: > Names normally have the form AREA/LOCATION, where AREA is a continent > or ocean, and LOCATION is a specific location within the area. > > The State of Palestine is the Palestine Time Zone owner, It has the > sole right to set, modify and register the Standard Time Zone; Name / > Database / DST. The Time Zone Database includes two zones related to Palestine, with the identifiers "Asia/Gaza" and "Asia/Hebron". These zones differ for (recent) historical reasons, because the rules for summer time (daylight saving time) varied during the period from 2008 to 2012. The file "asia" in the TZDB has comments which explain the exceptions for Gaza. By stating: > Palestine will use Palestine Standard Time (PSST), and Palestine > daylight time (PSDT). the PSI document appears to signal that the entire State of Palestine will observe a single changeover date and time, and will no longer observe different changeover dates in Gaza. However, for historical reasons involving the 2008–2012 daylight time discrepancies, both zones will continue to be reflected in TZDB. The TZDB administrators will retain the right to keep the identifiers "Asia/Gaza" and "Asia/Hebron", or to change them according to rules that they and the larger community have established. Governments or other bodies do not determine these identifiers, and cannot unilaterally claim the right to do so. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

1 0

No leap second on 2022-06-30
by Tim Parenti Jan. 11, 2022

Jan. 11, 2022

Per IERS, Bulletin C 63 (2022-01-05) https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.63 …and forwarded below. A patch updating leap-seconds.list from NIST is attached, and is installed in the development repository. -- Tim Parenti ---------- Forwarded message --------- From: IERS EOP Product Center <iers.eoppc(a)obspm.fr> Date: Wed, 5 Jan 2022 at 10:43 Subject: Bulletin C number 63 To: <bulc.iers(a)obspm.fr> INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE SERVICE DE LA ROTATION TERRESTRE DE L'IERS OBSERVATOIRE DE PARIS 61, Av. de l'Observatoire 75014 PARIS (France) Tel. : +33 1 40 51 23 35 e-mail : services.iers(a)obspm.fr http://hpiers.obspm.fr/eop-pc Paris, 05 January 2022 Bulletin C 63 To authorities responsible for the measurement and distribution of time INFORMATION ON UTC - TAI NO leap second will be introduced at the end of June 2022. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s Leap seconds can be introduced in UTC at the end of the months of December or June, depending on the evolution of UT1-TAI. Bulletin C is mailed every six months, either to announce a time step in UTC, or to confirm that there will be no time step at the next possible date. Christian BIZOUARD Director Earth Orientation Center of IERS Observatoire de Paris, France

1 0

Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone
by Paul Eggert Jan. 5, 2022

Jan. 5, 2022

On 1/4/22 09:12, Eliot Lear via tz wrote: > The TZ update process here has no formal recognition of governments (any governments). Still, statements from governments, however they reach this group, tend to carry a lot of weight. Quite true. In the past we've given a lot of weight to official government documents, and we welcome future cooperation in this area as this will streamline communication. (All too often for many countries in the past, we've had to rely on third parties or the popular press to forward their governments' information to us, which has resulted in inaccuracies and delays in updating the database.) From the timekeeping point of view, the most important thing is to know the UTC offsets and the rules for when daylight saving time starts and stops in Palestine, and for technical reasons it's best to have this nailed down well in advance - preferably at least a year before rules change. Currently for Palestine, tzdb lists standard time of UTC+02, and it says daylight saving time starts at 00:00 on the first Saturday on or after March 24, and ends at 01:00 on the first Friday on or after October 23. Unfortunately, as far as I know these daylight saving time rules are not official, in that there's no official Palestinian government document listing these rules for future years; however, tzdb must put *something* in the database and that's the best guess we've come up with. If the government could publish an official document stating what the rules are for future years, we'd be happy to adjust tzdb to match that. Of lesser importance is the English-language abbreviation used for standard and daylight saving time in Palestine. (This is less important because most timekeeping applications do not rely on these abbreviations, as they are inherently ambiguous and somewhat deprecated anyway.) Here, tzdb attempts to follow common practice, and it currently uses the same longstanding abbreviations for time in Palestine that it uses for Cyprus, Egypt, Jordan, Lebanon, and Syria - namely "EET" and "EEDT" (short for "Eastern European Time" and "Eastern European Summer Time"). I am unaware of any English-language use of the abbreviations "PSST" and "PSDT" to refer to civil timekeeping in this area. However, if these abbreviations become popular in common practice we should change tzdb to incorporate them.

2 2

Re: [tz] The State of Palestine has adopted the first part of thespecification for its time zone
by Sanjeev Gupta Jan. 4, 2022

Jan. 4, 2022

On Tue, Jan 4, 2022 at 7:24 PM <heba.hamad(a)mtit.gov.ps> wrote: > What is meant in general is that the State of Palestine (the Palestinian > government) is the only authorized one to address the international > bodies, including IANA, to request any amendment, update, registration, > or anything else related to the subject, > That may be hard to enforce. I am in Singapore, so what happens if I write to this list with information on the time in Hebron, or whether Gaza and Ramallah have the same DST date or not? I would be unauthorised to address IANA and request an update. or to publish any official decisions regarding the time Zone of the State > of Palestine. > Of course. That is unobjectionable. -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane

2 1

[PATCH] Allow complication with tcc
by Arthur Williams Dec. 31, 2021

Dec. 31, 2021

In zic.c, some multi-line strings were surrounded in parenthesis which prevented tcc from parsing it. Maybe this is a complier bug, but don't think we gain anything by having the paren so just removed them. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 1ab636be..867c8d18 100644 --- a/zic.c +++ b/zic.c @@ -990,9 +990,9 @@ random_dirent(char const **name, char **namealloc) char const *src = *name; char *dst = *namealloc; static char const prefix[] = ".zic"; - static char const alphabet[] = ("abcdefghijklmnopqrstuvwxyz" + static char const alphabet[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" - "0123456789"); + "0123456789"; enum { prefixlen = sizeof prefix - 1, alphabetlen = sizeof alphabet - 1 }; int suffixlen = 6; char const *lastslash = strrchr(src, '/'); -- 2.34.1

2 1

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson Dec. 15, 2021

Dec. 15, 2021

A bit of necroposting from my August 2020 email (quoted in full below): > We should take the time to write up a good lengthy explanation of > the issues ("boilerplate"), because this a really important issue of > concern to many people in the world and the project has indeed > thought about it pretty carefully. Dismissing the inquiries because > they are repetitive makes it seem like we haven't, and that > unnecessarily upsets [people]. Has anyone done any work on this, or given thought to it? Serhii Trykoza (hopefully cc'd)'s github PR from the last hour (https://github.com/eggert/tz/pull/35, copied far below) raises the issue again. Please note that the tz project does not use github PRs for issue tracking or commit management, so the PR will likely be closed in short order, which is not an indication of merit. Speaking of boilerplates, I want to again suggest that if this is going to continue to be the project policy, there should be a github pull-request template that makes it clear pull requests are not considered appropriate. Also, when you create a pull request on github now, it reports, "Be sure to review the contributing guidelines." with a hyperlink to https://github.com/eggert/tz/blob/228a93f759cd5f2b0cca9e05eeee3d7cdea07ebf/…. It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]"), and the fact that the it's a plain text file (rather than CONTRIBUTING.md in markdown) makes it feel pretty unfriendly in the github world. Convertinf the file to markdown and making the "please don't use github pull requests" the first thing, rather than the last thing, would help to get the point across. (Indeed, perhaps that should be the *only* thing in the file that github links to.) -- jhawk(a)alum.mit.edu John Hawkinson John Hawkinson <jhawk(a)alum.mit.edu> wrote on Sat, 15 Aug 2020 at 18:52:58 EDT in <20200815225258.GA62055(a)alum.mit.edu>: > Date: Sat, 15 Aug 2020 18:52:58 -0400 > From: John Hawkinson <jhawk(a)alum.mit.edu> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Victor Perov <vic.gald(a)gmail.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv > Message-ID: <20200815225258.GA62055(a)alum.mit.edu> > In-Reply-To: <eggert/tz/pull/27/c673663957(a)github.com> > <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu> > > I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. > > We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. > > Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. > > In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). > There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. > > > Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 > at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > > > Thanks for bringing that to the mailing list (if I could shut off GitHub > > pull requests I would). > > Although you cannot do so, we can handle them a little bit better. > Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… > > You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") > > For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. > > https://github.com/eggert/tz/pulls?q=kiev > > Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. > > -- > jhawk(a)alum.mit.edu > John Hawkinson Serhii Trykoza <notifications(a)github.com> wrote on Mon, 6 Dec 2021 at 08:17:35 EST in <eggert/tz/pull/35(a)github.com>: > Date: Mon, 06 Dec 2021 05:17:35 -0800 > From: Serhii Trykoza <notifications(a)github.com> > To: eggert/tz <tz(a)noreply.github.com> > Cc: Subscribed <subscribed(a)noreply.github.com> > Subject: [eggert/tz] KyivNotKiev (PR #35) > Reply-To: eggert/tz > <reply+AAJWHPTK2DO6A5B34PZOC3N7XHXG7EVBNHHD7Z4WBI(a)reply.github.com> > Message-ID: <eggert/tz/pull/35(a)github.com> > X-GitHub-Sender: strikoza > > In September 2020, the English Wikipedia switched from using Kiev to Kyiv. > > https://en.wikipedia.org/wiki/KyivNotKiev > You can view, comment on, or merge this pull request online at: > > https://github.com/eggert/tz/pull/35 > > -- Commit Summary -- > > * KyivNotKiev - In September 2020, the English Wikipedia switched from using Kiev to Kyiv - https://en.wikipedia.org/wiki/KyivNotKiev > > -- File Changes -- > > M .gitignore (2) > M europe (4) > M theory.html (2) > M zone.tab (2) > M zone1970.tab (2) > > -- Patch Links -- > > https://github.com/eggert/tz/pull/35.patch > https://github.com/eggert/tz/pull/35.diff > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/eggert/tz/pull/35

4 9

[PATCH] Fix "el ds" typo in man pages
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

This fixes a typo that I introduced in 2014 when fixing glitches with '-' and italics in man pages. The typo is visible only when using traditional troff (as opposed to groff-compatible processors). --- date.1 | 2 +- newctime.3 | 2 +- newstrftime.3 | 2 +- newtzset.3 | 2 +- time2posix.3 | 2 +- tzfile.5 | 2 +- tzselect.8 | 2 +- zdump.8 | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/date.1 b/date.1 index 432cab1..1ecd63a 100644 --- a/date.1 +++ b/date.1 @@ -5,7 +5,7 @@ date \- show and set date and time .if n .nh .if n .na .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B date [ .B \*-u diff --git a/newctime.3 b/newctime.3 index cc56e2c..1b1790f 100644 --- a/newctime.3 +++ b/newctime.3 @@ -4,7 +4,7 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" diff --git a/newstrftime.3 b/newstrftime.3 index 887aba5..d68bc33 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -41,7 +41,7 @@ strftime \- format date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B "size_t strftime(char *restrict buf, size_t maxsize," diff --git a/newtzset.3 b/newtzset.3 index 05aa350..8aaa0ff 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -4,7 +4,7 @@ tzset \- initialize time conversion information .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B timezone_t tzalloc(char const *TZ); diff --git a/time2posix.3 b/time2posix.3 index fbb5766..2ea7edc 100644 --- a/time2posix.3 +++ b/time2posix.3 @@ -4,7 +4,7 @@ time2posix, posix2time \- convert seconds since the Epoch .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B time_t time2posix(time_t t); diff --git a/tzfile.5 b/tzfile.5 index e2f11b4..550b31d 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -10,7 +10,7 @@ tzfile \- timezone information \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like diff --git a/tzselect.8 b/tzselect.8 index a1ec8d0..69514e2 100644 --- a/tzselect.8 +++ b/tzselect.8 @@ -3,7 +3,7 @@ tzselect \- select a timezone .SH SYNOPSIS .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B tzselect [ .B \*-c diff --git a/zdump.8 b/zdump.8 index a5e2042..131a6cb 100644 --- a/zdump.8 +++ b/zdump.8 @@ -17,7 +17,7 @@ zdump \- timezone dumper \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The .B zdump program prints the current time in each -- 2.32.0

1 0

[PROPOSED] Fix Y2242 bug in tzdb tarball generation
by Paul Eggert Dec. 14, 2021

Dec. 14, 2021

Use pax format so that ‘make tarballs’ will still work after the year 2242. Without this patch, a far-future ‘make tarballs’ would fail for the same reason the following fails now with GNU tar: $ touch -d 2242-03-16T12:56:32Z future $ tar --format=ustar -cf tar future tar: value 8589934592 out of time_t range 0..8589934591 tar: Exiting with failure status due to previous errors This patch doesn’t change the tarball format for today’s releases since we don’t use any features requiring pax format, which means the tarballs stick to the ustar subset of pax. Although this issue was exposed by the recent switch to ustar format, the Y2242 bug has been present since the tzdb project began, due to historical tar format expiring in 2242 and to POSIX and GNU coming up with incompatible extensions to deal with this expiration. * Makefile (GNUTARFLAGS): Switch from --format=ustar to --format=pax --pax-option='delete=atime,delete=ctime'. * NEWS: Update description of tarball format change. --- Makefile | 3 ++- NEWS | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index d30227a..23dcc14 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ +GNUTARFLAGS= --format=pax --pax-option='delete=atime,delete=ctime' \ + --numeric-owner --owner=0 --group=0 \ --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ diff --git a/NEWS b/NEWS index edb9a1d..1106ef6 100644 --- a/NEWS +++ b/NEWS @@ -26,9 +26,12 @@ Unreleased, experimental changes instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead - of " ". For details about ustar format, please see + of " ". The two formats are planned to diverge more significantly + for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar + format becomes obsolete and the tarballs switch to pax format, an + extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, - <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Changes affecting documentation and commentary -- 2.33.1

2 1

[PATCH 1/4] Simplify tzselect by omitting old Bash workaround
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

* tzselect.ksh (doselect): Omit Bash 1.14.7 workaround that I wrote in September 1996, as Bash 1.14.7 hasn’t been supported for years and surely should not be used anyway for security reasons. Bash 2.0 came out in December 1996. --- tzselect.ksh | 8 -------- 1 file changed, 8 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 18fce27..832cf75 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -101,14 +101,6 @@ then esac done || exit } - - # Work around a bug in bash 1.14.7 and earlier, where $PS3 is sent to stdout. - case $BASH_VERSION in - [01].*) - case `echo 1 | (select x in x; do break; done) 2>/dev/null` in - ?*) PS3= - esac - esac ' else doselect() { -- 2.32.0

1 3

Anniversary
by Arthur David Olson Dec. 13, 2021

Dec. 13, 2021

Discussion at an online meeting today made me realize that, alas, we missed the recent 35th anniversary of the start of the time zone mailing list. Put 2026-11-25 on your calendars now.-) https://mm.icann.org/pipermail/tz/1986-November/008946.html @dashdashado

5 5

[PROPOSED] Distribute tarballs in ustar rather than gnu form
by Paul Eggert Dec. 13, 2021

Dec. 13, 2021

It recently came to my attention that tzdb tarballs are not generated in standard POSIX ustar format, but instead use a trivially different but nonstandard format. Fix this by switching to the standard format. * Makefile (GNUTARFLAGS): Add --format=ustar. * NEWS: Document the change. --- Makefile | 3 ++- NEWS | 10 ++++++++++ 2 files changed, 12 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c89c1be..fd312d9 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --numeric-owner --owner=0 --group=0 --mode=go+u,go-w --sort=name +GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ + --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ else :; \ diff --git a/NEWS b/NEWS index 572a161..edb9a1d 100644 --- a/NEWS +++ b/NEWS @@ -20,6 +20,16 @@ Unreleased, experimental changes reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. + Changes to build procedure + + Distribution tarballs now use standard POSIX.1-1988 ustar format + instead of GNU format. Although the formats are almost identical + for these tarballs, ustar headers' magic fields contain "ustar" + instead of "ustar ", and their version fields contain "00" instead + of " ". For details about ustar format, please see + "pax - portable archive interchange", IEEE Std 1003.1-2017, + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. + Changes affecting documentation and commentary Rename CONTRIBUTING to CONTRIBUTING.md and use Markdown format. -- 2.32.0

1 0

.UA uses both kiev.ua and kyiv.ua, sebastopol.ua, uzhgorod.ua
by Brian Inglis Dec. 11, 2021

Dec. 11, 2021

...and other spellings for backward compatibility and convenience e.g. odessa.ua, sebastopol.ua with sevastopol.ua reserved, uzhgorod.ua (no mention of uzhhorod.ua even as reserved); from: https://hostmaster.ua/2ld/ referenced by the Public Suffix List package. Headings translated: Public domains second level =========================== Thematic domains ---------------- com.ua in.ua org.ua net.ua Specialty domains ----------------- edu.ua gov.ua Geographical domains -------------------- cherkassy.ua cherkasy.ua ck.ua chernigov.ua chernihiv.ua cn.ua chernovtsy.ua chernivtsi.ua cv.ua crimea.ua dnepropetrovsk.ua dnipropetrovsk.ua dp.ua donetsk.ua dn.ua ivano-frankivsk.ua if.ua kharkov.ua kh.ua kharkiv.ua kherson.ua ks.ua khmelnitskiy.ua km.ua kiev.ua kyiv.ua kirovograd.ua kr.ua lugansk.ua lg.ua lutsk.ua lt.ua volyn.ua lviv.ua nikolaev.ua mk.ua odessa.ua od.ua odesa.ua poltava.ua pl.ua rovno.ua rivne.ua rv.ua sebastopol.ua sumy.ua sm.ua ternopil.ua te.ua uzhgorod.ua uz.ua vinnica.ua vn.ua yalta.ua zaporizhzhe.ua zp.ua zhitomir.ua zt.ua Reserved domain names --------------------- cr.ua khmelnytskyi.ua kropyvnytskyi.ua krym.ua kv.ua lv.ua mykolaiv.ua sb.ua sevastopol.ua sicheslav.ua vinnytsia.ua zaporizhzhia.ua zhytomyr.ua Technological domains --------------------- admin.ua ipv6.ua ns.ua ua.ua www.ua xn--mqa.ua dnssec.ua rdap.ua epp1.ua epp2.ua This documents that proposed alternative English spellings may be neither as common nor the issue as settled as the trolls claim. -- 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.]

1 0

Israel DST: Proposed Change of Start of DST
by Ephraim Silverberg Dec. 5, 2021

Dec. 5, 2021

The Minister of Interior, Ayelet Shaked, is proposing to change the Time Law so that DST will start in Israel at 2 a.m. on the *Friday *before the *second *Sunday of March. DST starts, according to the current law, at 2 a.m. on the Friday before the *last* Sunday in March. The proposed change has yet to be brought before the Knesset. I will endeavour to update the list if the proposed change receives Knesset approval.

2 2

America/SaoPaulo TZ still observing DST
by William Renan Santos (DHL Supply Chain) Dec. 4, 2021

Dec. 4, 2021

Hi, In Brazil the DST was revoked few years ago by government, but looks like the systems are still considering the DST change. I ran the tzupdater using latest file of tzdata and the systems are still considering 1 hour ahead in Sao Paulo. Could you please help me to review and point where in the tzdata file the DST for Brazil was removed? Thanks! William Santos LATAM - IT Products Sr Systems Analyst DHL Supply Chain Estrada da Cruz Grande, 1700 Louveira - SP ZipCode: 13290-000 Brazil Telephone: +55 19 3848 9377 william.r.santos(a)dhl.com<mailto:william.r.santos@dhl.com> www.dhl.com/supplychain<http://www.dhl.com/supplychain> DHL Supply Chain - Excellence. Simply delivered. [top_em]

3 2

Proposal: Sections for different kinds of backward links
by Stephen Colebourne Nov. 18, 2021

Nov. 18, 2021

I have taken a stab at splitting the `backward` file into sections. This is based on repeated observations made by multiple people that the file represents different kinds of Link. https://github.com/eggert/tz/pull/33 The sections I'm suggesting are: CROSS-ISO - These link across an ISO-3166 boundary EXCESS - These were added despite the locations having the same timekeeping since 1970 RENAMED - These are simple aliases/renames OBSOLETE - These are the most obsolete form of IDs FIXED - These are alternate names for fixed offsets I don't expect this PR to be merged as is - There will probably need to be some consideration as to the correct split, and as to whether each ID is in the correct section. The approach I've used is commented sections with stable section names. Alternate approaches to this problem are possible. For example, a new file could be created for each section. That seems to be more disruptive than the proposed approach. Note that in order for this change to be useful, the section names need to be considered part of the source file API, and maintained over time. thanks Stephen

5 16

Re: [tz] tz Digest, Vol 122, Issue 22
by nadir altinbas Nov. 14, 2021

Nov. 14, 2021

@ Comment; Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) May I remind to Alan Mintz ;On the "en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_population" list shows that Turkey is in Asia, One of the region where is called as Marmara region is in Europe . Turkey is in both of Asia and Europe. Coordinates for Turkey as follows; ------------------------------------------- Latitude: 38° 57' 26.43" N Longitude: 35° 14' 26.67" E ------------------------------------------ also in GPS DD coordinate; 38.9573415 35.240741 ----------------------------------------- Nadir Altinbas nadiraltinbas(a)yahoo.com n.altinbas On Sunday, November 14, 2021, 05:27:55 PM GMT+3, tz-request(a)iana.org <tz-request(a)iana.org> wrote: Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://mm.icann.org/mailman/listinfo/tz or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..." Today's Topics: 1. Re: Time(Winter-summer) setting discussions in Turkey and research about it (nadir altinbas) 2. Re: Time(Winter-summer) setting discussions in Turkey and research about it (Alan Mintz) ---------------------------------------------------------------------- Message: 1 Date: Sat, 13 Nov 2021 15:36:25 +0000 (UTC) From: nadir altinbas <nadiraltinbas(a)yahoo.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <2020539311.1385787.1636817785458(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Ok ! Paul, Thanks,wikipedia correction explanation was better. Nadir Altinbas n.altinbas On Saturday, November 13, 2021, 11:15:33 AM GMT+3, Paul Eggert <eggert(a)cs.ucla.edu> wrote: Thanks for the heads-up. If Turkey actually changes its time zones or daylight-saving rules please let us know. I hope they give us plenty of warning (such as a year or more); otherwise, their cell phones and/or computers will likely be off. One minor point. The text says "Saatlerini de?i?tirmeyen en b?y?k ?lkeler ?in, Hindistan ve Japonya" which Google translates as "The largest countries that do not change their clocks are China, India and Japan." Using the Wikipedia list of countries by population[1], the ten most populous countries that do not observe daylight saving time are China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, Japan, and Ethiopia, in that order. [1] https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… ------------------------------ Message: 2 Date: Sat, 13 Nov 2021 10:48:15 -0800 From: Alan Mintz <alan.mintz(a)gmail.com> To: Paul Eggert <eggert(a)cs.ucla.edu> Cc: Time Zone Mailing List <tz(a)iana.org>, nadir altinbas <nadiraltinbas(a)yahoo.com> Subject: Re: [tz] Time(Winter-summer) setting discussions in Turkey and research about it Message-ID: <CAMLM5-Vkqs_k7HkGy+MPwWGcjAUzRXhu4OOkAdFywvy-Ppj5rw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Sat, Nov 13, 2021 at 12:15 AM Paul Eggert via tz <tz(a)iana.org> wrote: > ... Using the Wikipedia list of countries by population[1], the ten > most populous countries that do not observe daylight saving time are > China, India, Indonesia, Pakistan, Brazil, Nigeria, Bangladesh, Russia, > Japan, and Ethiopia, in that order. > > [1] > > https://en.wikipedia.org/wiki/List_of_countries_and_dependencies_by_populat… > Kind of a misleading statistic, though, since Indonesia straddles the equator and much of Brazil, Nigeria, and Ethiopia are within 15 degrees latitude, making DST unnecessary for them. -- Alan Mintz <Alan.Mintz(a)gMail.com>

1 0

Time(Winter-summer) setting discussions in Turkey and research about it
by nadir altinbas Nov. 13, 2021

Nov. 13, 2021

Thank You Paul! Resending e -mail message as plain Text as follows.Amendment e -mail; GMT+2.30 adviced by Turkeys Electrical Engineers Society (TMMOB-EMO) for eficiently enery usage in the country, on the news dealing with conflict while settings winter and summer time through organization. here is the link about news as Turkish; (www.emo.org.tr/genel/bizden_detay.php?kod=136372&tipi=5&sube=0) There also mentioned a research by ITU (Istanbul technical University research about time arrangement. These are just discussions and advice not officially anouncment. nadiraltinbas(a)yahoo.com Nadir Altinbas n.altinbas

3 3

Tİme zone discussions in Turkey and research about it
by nadir altinbas Nov. 12, 2021

Nov. 12, 2021

For GMT +2.30 adviced from Turkey's Electrical Engineers Society (TMMOB-EMO) reported on Social mediato efficient energy usage in Turkey. news here on the link as follows;EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | | | | | | | | | EMO - SAATLERE AYAR ARANIYOR (OKSİJEN) | | | This research is not official now.It may be considered future plan nadiraltinbas(a)yahoo.com n.altinbas

1 0

Pre-1970 data
by Stephen Colebourne Nov. 12, 2021

Nov. 12, 2021

How can this project successfully handle pre-1970 data? Why have I focussed so much on IDs and their value to tzdb? Intro ------- In previous threads I've focussed on IDs, and laid out different ways to describe the groups of IDs we have. For now, lets focus solely on the two main groups - region IDs, which represent abstract regions where clocks have been the same since 1970 - non-region IDs, which represent locations where tzdb has, at some point, added an ID The key observation is that the segregation between these two groups of IDs *did not exist* until around 2014. It was only in 2018 that the ISO country rule was removed. It has only been since 2014 or so that IDs have been merged. What tzdb previously offered was a set of IDs, based on a simple rule - "ID as needed for post-1970 data, with at least one per ISO country". Full history was available for each of these (whether accurate or not). What has happened since is a split, where no split previously existed. A split which favours some locations over others. The recent mailing list debates merely represent the cumulation of this favouritism. The irony is that the merges are being done in the name of equity and fairness, when the outcome has actually been the exact opposite - picking favourites, and denigrating everywhere else. That the approach to picking favourites is according to a standardised largest city rule isn't really that relevant here - it is the outcome that is unfair, not the process. If region IDs were of different appearance (eg. numeric or textually different) then the issues would not have arisen. The mistake was taking a fully functional and fully integral set of IDs, and bifurcating it into two groups. The split was actually a huge change in the policy of tzdb, which has been added drip by drip, rather than something that was ever fully appreciated up front. FWIW, it is clear to me that there is an aspect of imposing a US-centric timezone system on other parts of the world. The recent tzdb approach of focussing entirely on timezone regions makes perfect sense for the US, where region boundaries do not follow state lines, and ordinary members of the public need to be aware of whether they are in US/Mountain or US/Central. This simply isn't the timezone model in many other parts of the world. In places like Europe and Asia, the timezone is driven primarily by the country you live in - an ordinary member of the public in Iceland is never going to associate with some abstract timezone region stretching down the Atlantic that is not named, not legally defined and is little more than a random outcome based on tzdb's choice of 1970. Even in somewhere like Norway, an ordinary member of the public will understand that although they follow CET, their timezone is actually driven by their Government in Oslo. The brilliance of the original rule - "ID as needed for post-1970 data, with at least one per ISO country" - was that it seamlessly handled *both* models of timezone in one unified set of IDs. Removal of the ISO country part has completely destabilised that balance. As a constraint to this thread, tzdb really needs to offer one standard view of data, not command line flags that allow different views. If downstream projects end up with different views of the data, it makes tzdb a much less reliable source. (tzdb can be packaged in different ways on the same machine, for example it is undesirable for Postgres' internal tzdb and the OS tzdb to diverge for the same version). Given this, what needs to be nailed down is what is the default data set that tzdb publishes - there isn't really much point in talking about compile time flags, or that the contents of backzone could be used by someone. Lets look at seven options for pre-1970 data: Pre-1970 data for regions only ----------------------------------------- 1) Pre-1970 data for regions only - Despite looking identical to other IDs, region IDs are treated as special/favoured - Pre-1970 data for non-region IDs is of no importance whatsoever, thus most get pre-1970 data from another country/continent - The split between region and non-region locations is fully completed - the US-centric timezone model is dominant - An end user in Iceland is supposed to use Africa/Abidjan, Europe/Reykjavik is treated as a historical mistake of tzdb kept around only for backwards compatibility Pre-1970 data for most IDs ------------------------------------ 2) Pre-1970 data for each ID meeting the rule "ID as needed for post-1970 data, with at least one per ISO country" - The split between region and non-region locations is healed - High quality data from places like Iceland and Norway is retained, but low quality data from elsewhere is restored - The pre-1970 data is simply viewed as the best available data for the each location which can be improved over time - Most end-users in Iceland would expect tzdb to provide pre-1970 data from Iceland, not the Ivory Coast 3) Pre-1970 data for for all IDs that currently exist except true aliases - This is very similar to #2, but would include something like Montreal which was effectively mistakenly added to tzdb - This doesn't seem as desirable as #2 4) Pre-1970 data for any ID where the pre-1970 data is high quality - Subjective on quality, which doesn't seem like a great idea - It does avoid bringing bad quality data back into the main tzdb distribution - On balance, #2 has fewer places for debate to arise 5) Pre-1970 data for all IDs that currently exist except true aliases, plus a *new* set of IDs representing regions - As per #2, but adding IDs like "Region/12345" or "Region/Berlin" - Regions should contain post-1970 data only, as the region is by definition only meaningful post-1970 - It is not entirely clear what this solves over just going with #2 - This option is connected to Russ' proposals [1], although he suggests a bigger split between timekeeping data and ID naming - Perhaps it makes sense if the new region IDs were internal and not normally seen by end users? Remove pre-1970 data from general use ------------------------------------------------------- 6) No pre-1970 data whatsoever, all IDs are post-1970 only - Project policy is that tzdb is focussed on post-1970 data only - Paul repeatedly tells us that pre-1970 data is unreliable, and people shouldn't use it - Pre-1970 data would not be deleted, but would not be available in most downstreams - The split between region and non-region locations is effectively healed - End users lose access to pre-1970 data, which is particularly notable in some locations where that data is reliable, eg London - It is unknown at this point what the user impact is of removing pre-1970 data from major financial/business centres (no major location has yet been merged) 7) No existing IDs get pre-1970 data, but a *new* set of IDs are created containing it - As per #5, the existing IDs get no pre-1970 data and the split between region and non-region locations is healed - New IDs, such as "Historic/Europe/London" or "Historic/Africa/Abidjan" get created for each of the main IDs - The historic IDs include pre-1970 data, the standard IDs do not - There is a mechanical transformation between the historic and non-historic IDs - Whether downstreams do or do not include the historic IDs is their choice, potentially based on available space - The data provided by the standard non-historic IDs remains the same whether the downstream includes the historic IDs or not (a Good Thing) - Users have to deliberately opt-in to get pre-1970 data, which might make them think about the accuracy issue Notes -------- - I'm not discussing adding new IDs simply to represent locations whose clocks differ only before 1970. I don't personally think that is a job for tzdb, and even if it is, it is a job for a different thread. - I'm not discussing what value is returned prior to 1970 when pre-1970 data is removed. That would be a job for a different thread. - Link vs Zone is not important for this discussion. Summary ------------- After a few weeks of thinking, these are the options I've come up with. Feel free to suggest another option or variant if you think I've missed anything obvious. I believe that was a disaster that the brilliant "ID as needed for post-1970 data, with at least one per ISO country" rule was removed. It has created needless division, bifurcating a unified set of ID into region and non-region IDs and creating backwards compatibility issues in the data of many locations. IMO, there are two basic models of timezones in the world, and moving tzdb from one that supported both to one that only supports the US-centric model is simply a mistake that needs correcting. As such, my preference would be to adopt option 2. Option 6 or 7 could work, and might be the best choices if we had a clean slate or if there was some hidden pressure that the list is unaware of to remove pre-1970 data, but they are risky options given we do not know the impact on end-users in major financial/business centres. Stephen [1] https://mm.icann.org/pipermail/tz/2021-September/030518.html

23 59

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