- tz - lists.iana.org

[PATCH 1/3] * backward: Add backward-compatibility comment.
by Paul Eggert July 21, 2022

July 21, 2022

--- backward | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/backward b/backward index a8fd620..5a86400 100644 --- a/backward +++ b/backward @@ -8,6 +8,10 @@ # also present in the file 'backzone', which has data important only # for pre-1970 timestamps and so is out of scope for tzdb proper. +# Although this file is optional and tzdb will work if you omit it by +# building with 'make BACKWARD=', in practice downstream users +# typically use this file for backward compatibility. + # Link TARGET LINK-NAME Link Africa/Nairobi Africa/Asmera Link Africa/Abidjan Africa/Timbuktu -- 2.36.1

1 2

Re: [tz] Fixing GeoNames timezone error
by dpatte July 19, 2022

July 19, 2022

I may be mistaken, but these other zones may be based on Indigenous reservations in these areas, some of which may not have used daylight saving time. ----- Original Message ----- From: Chris Walton via tz [mailto:tz@iana.org] To: "Evan Siroky" <evan.siroky(a)yahoo.com> Cc: kerry(a)shetline.com, tz(a)iana.org Sent: Tue, 19 Jul 2022 12:49:12 -0400 Subject: Re: [tz] Fixing GeoNames timezone error I mentioned earlier in this email thread that a large portion of Ontario (including the city of Barrie) is currently within the America/Nipigon boundary in Openstreetmap (OSM). I am 100% convinced the boundary is completely wrong. e.g. #1: The city of Barrie has been using daylight saving (during summer months) since at least 1930 which means it should be included within the America/Toronto boundary instead of the America/Nipigon boundary. Here are some newspaper pages containing Barrie daylight saving announcements for several different years that I picked at random: 1930: https://news.ourontario.ca/2760660/page/1835517 1946: https://news.ourontario.ca/2909650/page/13 1960: https://news.ourontario.ca/2919309/page/2280030 1970: https://news.ourontario.ca/2914181/page/2325462 1972: https://news.ourontario.ca/2917630/page/2349924 e.g. #2: I found documented proof that Prince Edward County was using daylight saving in 1970 which means it too should be moved from America/Nipigon to America/Toronto. Realistically it has probably been using daylight saving since WWII or earlier. The Kingston Whig Standard published this blurb on April 25, 1970:PICTON — Clocks go ahead one hour here Saturday night or Sunday morning, whichever you prefer, as Daylight Saving Time takes over in Prince Edward County. OSM mapper "ArcticGnome" claims to have based the OSM boundaries for America/Nipigon and America/Toronto on Shanks and Pottenger's International Atlas without realizing that much of the Shanks & Pottenger data was fake. Both myself and ArcticGnome are now pondering whether the inaccuracy of the data warrants eliminating the following zones from OSM. America/Nipigon America/Rainy_River America/Thunder_Bay America/Glace_Bay I believe that that decision should depend on whether Paul decides to continue maintaining them as dedicated zones in the TZ database. In my opinion, none of the data for these zones is trustworthy. America/Nipigon: Currently the TZ database shows that America/Nipigon adopted daylight saving in 1974. I don't have a complete history of daylight saving for Nipigon, but I did find a page from the Nipigon Gazette that clearly shows daylight saving ending for the 1972 season on October 29, 1972. https://news.ourontario.ca/npl/122271/page/2 The implication is that Nipigon has been using daylight saving since at least 1972 and therefore the data we are using for America/Nipigon is bogus. America/Rainy_River: I could not find any useful information to prove that the data for this zone is either correct or incorrect. America/Thunder_Bay: The TZ database shows that Thunder Bay and Toronto have been in sync since 1970 except for the year 1973. The database shows Thunder Bay skipped daylight saving in 1973. However, a relatively recent article in the Bayview Magazine seems to indicate that Thunder Bay did not actually skip daylight saving in 1973: http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… I sent an email to both the author of that article and one of the Thunder Bay archivists. In the email I asked for clarification about 1973. I will post here if I actually get a response. America/Glace_Bay: The TZ database shows Glace Bay adopted daylight saving in 1972. It is possible that this data is correct, but I am a bit skeptical. Glace Bay is a small town about 10km from Sydney. According to this document, Sydney was observing daylight saving in the year 1969: https://articles.adsabs.harvard.edu//full/1970JRASC..64..129T/0000135.000.h… There is no compelling reason to believe that Sydney would have abandoned daylight saving in 1970 and 1971. And there is no compelling reason to believe that Glace Bay would have kept its clocks out of sync with Sydney during the summers of 1970 and 1971. The truth about Glace Bay (and other communities in Cape Breton) will likely exist in the archives of the Cape Breton Post which are maintained on microfilm at the Cape Breton Regional Library in Sydney and at the Nova Scotia Archives in Halifax. -chris On Fri, 8 Jul 2022 at 05:33, Evan Siroky <evan.siroky(a)yahoo.com> wrote: I agree with Chris. I'm adding a reference to the GitHub issue that Kerry created. https://github.com/evansiroky/timezone-boundary-builder/issues/131 Evan On Friday, 8 July 2022 at 04:22:26 am GMT+2, Chris Walton via tz <tz(a)iana.org> wrote: The Nipigon/Toronto is a pet peeve of mine. It is the result of some questionable data inside Openstreetmap (OSM). Nipigon is a small township in Northern Ontario with a population of 1473 and an area of 108 square km. To put this into perspective: -Nipigon contains 0.01% of Ontario's total population. -Nipigon makes up 0.01% of Ontario's total land area. Inside OSM, somebody moved 73% of the land in Ontario into the America/Nipigon timezone. It was done with about 120 separate changesets between February and June of 2020. Some of the changesets have no source; others list "Shanks" as a reference. After following this mailing list for 15 years, I am very skeptical of the work published by Shanks, but I am in no position to prove it is wrong. I am also skeptical that anybody travelling directly by car from Windsor to Montreal (post 1970) would have had to pass through multiple time zone regions. The OSM relations are listed below. Note that if you click on the OSM links, the colour orange is used for both inner and outer boundaries thus the inner polygons are "holes" or "excluded areas". Without shading, it is not always simple to recognize this. The relations are large and may take some time to load in your browser. OSM America/Toronto relation: Includes most of Quebec and most urban centres in Ontario. Area: 1,546,844.1 square km. https://www.openstreetmap.org/relation/6483867#map=5/53.592/-73.135 OSM America/Nipigon relation: Includes most rural areas of Ontario east of 90°W Also includes a few populated centers such as Sarnia (pop: 72,047) and Barrie (pop: 147,829). Area: 787,493.2 square km. https://www.openstreetmap.org/relation/6498592#map=6/45.982/-81.573 >From a daylight saving standpoint, both zones have been the same since 1974. It would be very helpful if somebody could accurately determine when Barrie and Sarnia started using daylight saving (without using Shanks or OSM as a reference). -chris On Thu, 7 Jul 2022 at 15:11, Kerry Shetline via tz <tz(a)iana.org> wrote:I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point. > Evan Siroky <evan.siroky(a)yahoo.com> writes: > > Hello, > I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. > Evan

1 0

Re: [tz] Fixing GeoNames timezone error
by Kerry Shetline July 19, 2022

July 19, 2022

I’ll post a more detailed comment on GitHub later, and link to my own code where I’m trying to use your boundaries to solve some of these issues. For the example of Walpole Island, Ontario, when I try to find a zone that contains the lat/long of this location, I oddly get the match for America/Nigipon rather than America/Toronto (at least it’s not America/Detroit, as GeoNames has it). I get several matches, in fact, for America/Nigipon that don’t make sense, given that this zone should have a very small area. I’m using the @turf/turf npm library to parse the shape files, and booleanPointInPolygon() to check if a particular zone contains a specific lat/long point. > Evan Siroky <evan.siroky(a)yahoo.com> writes: > > Hello, > I'm the maintainer of?https://github.com/evansiroky/timezone-boundary-builder?which is a project that?extracts data from Open Street Map (OSM) to build shape files of the boundaries of the world's timezones. If you find inaccuracies with the data generated from this project, I'd love to know about these problems. Feel free to submit an issue in the GitHub project noting any problem that you see. > Evan

4 4

Re: [tz] [PROPOSED] New file tzdata.zi for text-format tzdata
by Dot T July 12, 2022

July 12, 2022

With a few exceptions, all files in the tz code and data (including this one) are in the public domain. The exceptions are date.c, newstrftime.3, and strftime.c, which contain material derived from BSD and which use the BSD 3-clause license.

1 0

Re: [tz] [PROPOSED] New file tzdata.zi for text-format tzdata
by Dot T July 12, 2022

July 12, 2022

With a few exceptions, all files in the tz code and data (including this one) are in the public domain. The exceptions are date.c, newstrftime.3, and strftime.c, which contain material derived from BSD and which use the BSD 3-clause license.

1 0

[PROPOSED 1/5] * zic.8: fix minus typo
by Paul Eggert July 12, 2022

July 12, 2022

--- zic.8 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zic.8 b/zic.8 index 0cd0781..e8816e5 100644 --- a/zic.8 +++ b/zic.8 @@ -145,7 +145,7 @@ outputs data intended only for nonnegative timestamps that fit into 31-bit signed integers. On platforms with GNU .BR date , -.q "zic \-r @$(date +%s)" +.q "zic \*-r @$(date +%s)" omits data intended for past timestamps. Although this option typically reduces the output file's size, the size can increase due to the need to represent the timestamp range -- 2.34.1

1 4

[PATCH] Add -R option to zic
by Paul Eggert July 12, 2022

July 12, 2022

(Need suggested by Almaz Mingaleev.) * NEWS, zic.8: Document option. * zic.c (usage): Mention new option. (redundant_time): New static var. (redundant_time_option): New function. (main, writezone, outzone): Support -R. --- NEWS | 4 ++++ zic.8 | 11 +++++++++++ zic.c | 44 +++++++++++++++++++++++++++++++++++++++++--- 3 files changed, 56 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 60deee4..850e38b 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Iran no longer observes DST after 2022. Rename Europe/Kiev to Europe/Kyiv. + New zic -R option Changes to future timestamps @@ -38,6 +39,9 @@ Unreleased, experimental changes Changes to code + zic has a new option '-R @N' to output explicit transitions < N. + (Need suggested by Almaz Mingaleev.) + 'zic -r @N' no longer outputs bad data when N < first transition. (Problem introduced in 2021d and reported by Peter Krefting.) diff --git a/zic.8 b/zic.8 index 3f228a6..0cd0781 100644 --- a/zic.8 +++ b/zic.8 @@ -159,6 +159,17 @@ Also see the .B "\*-b slim" option for another way to shrink output size. .TP +.BI "\*-R @" hi +Generate redundant trailing explicit transitions for timestamps +that occur less than +.I hi +seconds since the Epoch, even though the transitions could be +more concisely represented via the extended POSIX TZ string. +This option does not affect the represented timestamps. +Although it accommodates nonstandard TZif readers +that ignore the extended POSIX TZ string, +it increases the size of the altered output files. +.TP .BI "\*-t " file When creating local time information, put the configuration link in the named file rather than in the standard location. diff --git a/zic.c b/zic.c index 19e145a..e081c3d 100644 --- a/zic.c +++ b/zic.c @@ -579,7 +579,8 @@ usage(FILE *stream, int status) _("%s: usage is %s [ --version ] [ --help ] [ -v ] \\\n" "\t[ -b {slim|fat} ] [ -d directory ] [ -l localtime ]" " [ -L leapseconds ] \\\n" - "\t[ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -t localtime-link ] \\\n" + "\t[ -p posixrules ] [ -r '[@lo][/@hi]' ] [ -R '@hi' ] \\\n" + "\t[ -t localtime-link ] \\\n" "\t[ filename ... ]\n\n" "Report bugs to %s.\n"), progname, progname, REPORT_BUGS_TO); @@ -681,6 +682,9 @@ static zic_t const max_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t lo_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); static zic_t hi_time = MAXVAL(zic_t, TIME_T_BITS_IN_FILE); +/* The time specified by the -R option, defaulting to MIN_TIME. */ +static zic_t redundant_time = MINVAL(zic_t, TIME_T_BITS_IN_FILE); + /* The time specified by an Expires line, or negative if no such line. */ static zic_t leapexpires = -1; @@ -712,6 +716,22 @@ timerange_option(char *timerange) return true; } +/* Generate redundant time stamps up to OPT. Return true if successful. */ +static bool +redundant_time_option(char *opt) +{ + if (*opt == '@') { + intmax_t redundant; + char *opt_end; + redundant = strtoimax(opt + 1, &opt_end, 10); + if (opt_end != opt + 1 && !*opt_end) { + redundant_time = max(redundant_time, redundant); + return true; + } + } + return false; +} + static const char * psxrules; static const char * lcltime; static const char * directory; @@ -764,7 +784,8 @@ main(int argc, char **argv) } else if (strcmp(argv[k], "--help") == 0) { usage(stdout, EXIT_SUCCESS); } - while ((c = getopt(argc, argv, "b:d:l:L:p:r:st:vy:")) != EOF && c != -1) + while ((c = getopt(argc, argv, "b:d:l:L:p:r:R:st:vy:")) != EOF + && c != -1) switch (c) { default: usage(stderr, EXIT_FAILURE); @@ -851,12 +872,23 @@ _("%s: invalid time range: %s\n"), } timerange_given = true; break; + case 'R': + if (! redundant_time_option(optarg)) { + fprintf(stderr, _("%s: invalid time: %s\n"), + progname, optarg); + return EXIT_FAILURE; + } + break; case 's': warning(_("-s ignored")); break; } if (optind == argc - 1 && strcmp(argv[optind], "=") == 0) usage(stderr, EXIT_FAILURE); /* usage message by request */ + if (hi_time + (hi_time < ZIC_MAX) < redundant_time) { + fprintf(stderr, _("%s: -R time exceeds -r cutoff\n"), progname); + return EXIT_FAILURE; + } if (bloat == 0) { static char const bloat_default[] = ZIC_BLOAT_DEFAULT; if (strcmp(bloat_default, "slim") == 0) @@ -2139,7 +2171,10 @@ writezone(const char *const name, const char *const string, char version, rangeall.defaulttype = defaulttype; rangeall.count = timecnt; rangeall.leapcount = leapcnt; - range64 = limitrange(rangeall, lo_time, hi_time, ats, types); + range64 = limitrange(rangeall, lo_time, + max(hi_time, + redundant_time - (ZIC_MIN < redundant_time)), + ats, types); range32 = limitrange(range64, INT32_MIN, INT32_MAX, ats, types); /* TZif version 4 is needed if a no-op transition is appended to @@ -2893,6 +2928,8 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) max_year = min_year + years_of_observations; } } + max_year = max(max_year, (redundant_time / (SECSPERDAY * DAYSPERNYEAR) + + EPOCH_YEAR + 1)); max_year0 = max_year; if (want_bloat()) { /* For the benefit of older systems, @@ -3061,6 +3098,7 @@ outzone(const struct zone *zpfirst, ptrdiff_t zonecount) offset = oadd(zp->z_stdoff, rp->r_save); if (!want_bloat() && !useuntil && !do_extend && prevrp && lo_time <= prevktime + && redundant_time <= ktime && rp->r_hiyear == ZIC_MAX && prevrp->r_hiyear == ZIC_MAX) break; -- 2.34.1

1 0

to Pierre Cashon
by Petro Ordynskyi July 12, 2022

July 12, 2022

1 0

Moderation note 2
by Petro Ordynskyi July 12, 2022

July 12, 2022

1 0

Timezone error (Kyiv not Kiev)
by Yana Sukhoversha July 12, 2022

July 12, 2022

Dear Sirs and Madams, I've noticed the Timezone error , the correct spelling according to orthographic rules is Kyiv not Kiev. I hope this accidental mistake will be amended urgently , taking into consideration Ukrainian-Russian relations nowadays as well as your strive to improvement and lightning-fast response to error corrections Hope to see the correct variant Kyiv very soon Sincerely, *Yana Sukhoversha*

10 14

Moderation note
by Kim Davies July 12, 2022

July 12, 2022

We have temporarily introduced some moderation controls in light of the repetitive and externally coordinated nature of the Kyiv naming requests being sent to this group. This is not a measure we take lightly. Continuous restatement of the same talking points and casting aspersions at people's motives does not advance productive discussion and drives well intentioned participants away. I would encourage all participants to not relitigate the same arguments back and forth that are now very familiar to list members. It is useful to consider ICANN's expected standards of behavior which can be reviewed at https://www.icann.org/resources/pages/expected-standards-2016-06-28-en kim -- Kim Davies VP, IANA Services, ICANN President, PTI

1 0

Why Kyiv has not been changed yet?
by Artur Nakonia July 10, 2022

July 10, 2022

Hello, What is the problem with Kyiv? Why it is still as Kiev? Thank you, Artur Nakonia

2 2

Absolute error to use Kiev instead of Kyiv
by Pavlo Neberelytskyi July 10, 2022

July 10, 2022

Hi, There is an error in naming Kiev instead of Kyiv. Kyiv is the only correct variant since 1992, please correct. Thanks, Pavlo

1 0

Re: [tz] Moving more zones to 'backzone'
by dpatte July 9, 2022

July 9, 2022

Thank you. This is something I have been trying to say as well. The db format should allow us to collect historical tz information for any region, even locations that are only different before 1970. This is of use for those that do historical time-of-day research in any field, such as astronomy. Eventually all locations on earth, going backward, revert to local solar (sundial) time, so we only need to collect data which is other than local solar time, generally going back to the dates of implementation of local mean time for various locations. Obviously, such a collection can never be complete, like any historical data, but it does provide information which is useful to some, and constantly improving. ----- Original Message ----- From: Christos Zoulas via tz [mailto:tz@iana.org] To: "Time zone mailing list" <tz(a)iana.org> Sent: Sat, 9 Jul 2022 07:01:08 -0400 Subject: Re: [tz] Moving more zones to 'backzone' I view maintaining the pre-1970 data as an exercise in improving the historical record of timezone information. Historians don't simply discard information when they are not certain about its accuracy. They constantly work to make it better. In extreme cases it is called https://en.wikipedia.org/wiki/Historical_revisionism. I don't see any other group of people trying to do this work, so like it or not we are the best positioned group to maintain this information right now. I believe that we should provide the best information to our knowledge instead of giving up and discarding it because of convenience. I also agree with kre that the arcane zic format needs to be redesigned to ease maintenance. Best, christos

1 0

On simultaneously experiencing daylight
by Tim Parenti July 8, 2022

July 8, 2022

A friend shared an article investigating a recent claim on Reddit that earlier today, 8 July 2022, at 11:15 UTC, "99% of the world’s population" would simultaneously find themselves between dawn and dusk. This claim was soon popularized into a related claim that a similar percentage would "experience daylight" at that time. https://earthsky.org/earth/99-percent-worlds-population-receive-sunlight/ Spoiler: The original claim of 99% holds only if you use the most *technical* definition of twilight — including civil, nautical, and astronomical. In practice, most folks living in areas falling into the latter categories would perceive nighttime. But, as the article goes on to explore, however you slice it, it's still an impressive percentage of the global population "experiencing daylight" by any definition. -- Tim Parenti

1 0

question re zone America/Punta_Arenas in Chile
by Alois Treindl July 7, 2022

July 7, 2022

In 2016, Chile introduced a new time zone for it south-most province Magallanes, and for this reason a new zone Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03 has been created. before it followed Zone America/Santiago -4:42:46 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1946 Jul 15 -4:00 1:00 -03 1946 Sep 1 # central Chile -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 The new zone differs from zone Santiago at two points: - it does not have the 1946/47 DST - it differs from 2016 Dec 4, the reason of its creation. I wonder on which basis the 1946/47 DST was left out for Puntas_Arenas? Is that documented somewhere? The main reason why I ask: My two sources Shanks and Gabriel have always claimed that zone America/Santiago is only good for the province of Santiago, but that the rest of Chile did not have DST between 1927 and 1932. This is why in my private pre-1970 TZ extension I have an extra zone for 'rest of Chile besides Santiago' Zone America/Chile/Antofagasta -4:41:36 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 0 follow America/Santiago which leaves out the 1927-1932 DST. It has however the 1946/47 DST. I have another zone, based on Shanks and Gabriel, for Vaparaiso, which leaves out the 1946/47 DST, but has a one-summer 1931/1932 DST. Zone America/Chile/Vina_del_Mar -4:46:16 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 # Santiago Mean Time -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1931 Sep 1 -5:00 Chile -05/-04 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 0 follow America/Santiago Sadly, I have currently no sources for that beyond Shanks and Gabriel. We would need local newspaper archives from a non-Santiago newspaper for 1927-1932 to confirm. But it this is true, we have to assume that province Magellanes behaved like 'the rest of Chile' and not like Santiago before the split in 2016. That means that it should be: Zone America/Punta_Arenas -4:43:40 - LMT 1890 -4:42:46 - SMT 1910 Jan 10 -5:00 - -05 1916 Jul 1 -4:42:46 - SMT 1918 Sep 10 -4:00 - -04 1919 Jul 1 -4:42:46 - SMT 1927 Sep 1 -5:00 - -05 1932 Sep 1 -4:00 - -04 1942 Jun 1 -5:00 - -05 1942 Aug 1 -4:00 - -04 1947 Apr 1 -5:00 - -05 1947 May 21 23:00 -4:00 Chile -04/-03 2016 Dec 4 -3:00 - -03

4 6

Re: [tz] Fixing GeoNames timezone errors
by dpatte July 6, 2022

July 6, 2022

I use the free geonames database in several of my projects. It is a user-contributed db, so all users are welcome to make corrections. They also have a paid version which is more heavily scrutinized for errors. ----- Original Message ----- From: Kerry Shetline via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Wed, 6 Jul 2022 15:50:02 -0400 Subject: [tz] Fixing GeoNames timezone errors For those not familiar with the website, geonames.org provides a Creative Commons-licensed database of city, towns, geographic features, etc. Among other things, this DB provides latitude, longitude, and IANA timezone for millions of places around the world. The problem is I’m finding many of the timezone values provided in this DB are incorrect. This mostly seems to be caused by places with coordinates near timezone boundaries being incorrectly assigned a nearby but incorrect timezone. For example, Walpole Island, Ontario, Canada, right next to the US border, is set to America/Detroit instead of the correct value of America/Toronto. It’s at least easy to spot some errors like this, when a particular timezone is known to definitely belong to a different country, but there are many other errors at national, and state/province/prefect/etc. boundaries not so easy to spot. I was trying to create a timezone lookup based on country, state (admin level 1), and county (admin level 2) by going through the millions of entries in the database, building lists of which timezones were used where, but it quickly became apparent that the data was contaminated by many errors. Does anyone know of a more reliable source for determining the timezone of a location on Earth, either by its latitude and longitude, or by the country and other administrative hierarchy information? I’ve found downloads of shape files meant to define timezone boundaries, but they don’t seem to be very accurate. In fact, I suspect that the use of inaccurate timezone boundaries is the source of many of the errors in the Geonames DB, and that Geonames isn't even applying the help of the zone.tab file to rule out some of the errors caused by this.

1 0

Fixing GeoNames timezone errors
by Kerry Shetline July 6, 2022

July 6, 2022

For those not familiar with the website, geonames.org provides a Creative Commons-licensed database of city, towns, geographic features, etc. Among other things, this DB provides latitude, longitude, and IANA timezone for millions of places around the world. The problem is I’m finding many of the timezone values provided in this DB are incorrect. This mostly seems to be caused by places with coordinates near timezone boundaries being incorrectly assigned a nearby but incorrect timezone. For example, Walpole Island, Ontario, Canada, right next to the US border, is set to America/Detroit instead of the correct value of America/Toronto. It’s at least easy to spot some errors like this, when a particular timezone is known to definitely belong to a different country, but there are many other errors at national, and state/province/prefect/etc. boundaries not so easy to spot. I was trying to create a timezone lookup based on country, state (admin level 1), and county (admin level 2) by going through the millions of entries in the database, building lists of which timezones were used where, but it quickly became apparent that the data was contaminated by many errors. Does anyone know of a more reliable source for determining the timezone of a location on Earth, either by its latitude and longitude, or by the country and other administrative hierarchy information? I’ve found downloads of shape files meant to define timezone boundaries, but they don’t seem to be very accurate. In fact, I suspect that the use of inaccurate timezone boundaries is the source of many of the errors in the Geonames DB, and that Geonames isn't even applying the help of the zone.tab file to rule out some of the errors caused by this.

2 1

Re: [tz] Timezone error (Kyiv not Kiev)
by Stephen Trainor (Crookneck) July 6, 2022

July 6, 2022

Steve Summit wrote: > What end-user interfaces are there that present raw tz identifiers > for selection, and that might therefore confuse or offend users > if the spellings are culturally inappropriate? I’ve seen them shown (and have used them myself 'as-is') in multiple astronomy apps. (I double checked some apps today, and they are there.) I’ve never quite understood the "don’t show them to the user" argument. When I first became involved in using time zone data in a desktop application some years ago (via geonames and other downstream tzdata repackaging projects), from memory there was no mention of this guidance. It would be wrong to assume downstream consumers even know about it. And given that TZ IDs conspicuously pass the "duck test” it’s hardly surprising to see them making public appearances. They appear perfectly suited to show in a UI (with underscores replaced by spaces, I suppose). That said, replacing them with an anonymous identifier (e.g. 7252) would be a major negative for usability of the data (at least from a development/testing perspective). And while it would kick the problem downstream, it’s not going to eliminate it. I imagine many of the new set of downstream TZ ID-to-human readable translation errors or disputes that would undoubtedly ensue would land back on this list anyway. > As regulars well know, but newcomers may not, time zone identifiers > are just that: identifiers. True, but clearly there’s major inertia when it comes to changing them, as evidenced by the last several years of debate on K**v. So which is it? Easily mutable identifiers that users supposedly never see or human consumable ‘readable’ IDs?

3 4

Error Correction Request: Europe/Kiev to Europe/Kyiv
by Ivanka Kvitka July 5, 2022

July 5, 2022

Hello, Please be aware that 'Kiev' is an error. The correct name is 'Kyiv'. When are you planning to correct the mistake? Please advise. Best regards, -- Iavanka Kvikta Russia is a terrorist country and I am not afraid to say it!

5 8

tzdata comments link to an April Fools article
by Jeff Epler July 5, 2022

July 5, 2022

I was poking around and found the following in the "australiasia" file: # From Paul Eggert (2018-04-01): # The Guardian Express of Perth, Australia reported today that the # government decided to advance the clocks permanently on January 1, # 2019, from UT +08 to UT +09. The article noted that an exemption # would be made for people aged 61 and over, who "can apply in writing # to have the extra hour of sunshine removed from their area." See: # Daylight saving coming to WA in 2019. Guardian Express. 2018-04-01. # https://www.communitynews.com.au/guardian-express/news/exclusive-daylight-s… However, this article is a joke (note that it is dated April 1 and says some rather silly things). Maybe everyone was in on the joke, but I very nearly wasn't. I think it would be best if this reference were removed or if not clearly marked as humor. In the unlikely event that this actually reflects reality, perhaps a different reference could be used. Please cc: me on replies. Jeff

7 7

the tzdb information schema
by Michael H Deckers July 4, 2022

July 4, 2022

Some recent difficulties with tzdb updates have led me to consider how they could have been avoided. • The fact that two timezones agree since 1970 is not represented independently from the data of each timezone. This leads to "update anomalies" well-known from database theory. For instance, before Africa/Khartoum switched to UTC - 02 h in 2017, Africa/Juba was a link (in the file africa) to Africa/Khartoum. After the switch, new Zone data for Africa/Juba had to appear in the file africa. Actually, Zone data for Africa/Juba had survived in the file backzone but this was overlooked, so that we had Zone data for Africa/Juba in both files africa and backzone from 2017c until 2018b, and these Zone data did not even agree. And all this happened for Africa/Juba even though civil time in Juba was not changed at all at the time. It appears that this error would not have happened if all African Zone data had been kept in the file africa (rather than in africa and in backzone) -- it was not the Zone data of Africa/Juba that had changed, but only the fact that Africa/Juba ws merged with Africa/Khartoum because their Zone data agreed since 1970. Unfortunately, this fact was not (and still is not) representable as an independently changeable item in tzdb. • Most of the Zone data currently contained in the file backzone have in earlier versions been stored in the "continental" files (africa, antarctica, asia, australasia, europe, northamerica, southamerica), and the reason why they are in backzone is that their Zone data agree with other Zone data since 1970. And since this may well change in the future, we have to keep these Zone data in backzone current. The file backzone is an integral part of the tzdb data, not just a container for additional data of lesser quality. The quality of any Zone data (and any Rule data) in tzdb should always be "to the best of our current knowledge" -- it just does not make sense to keep Zone data in tzdb that are not updated when we acquire relevant new information for them. Thus we should get rid of Zone data for Argentina/Rosario etc (or else update them); keeping data that are known to be wrong is not only useless, it is an invitation for consequential errors. • Letting derived data (such as whether two timezones should be merged because they agree since 1970) decide about the storage location of the Zone data for a timezone not only implies unnecessary data moves upon data updates, it may also disrupt commentary text and its references. Easily understandable comments (such as which facts were deduced from which document) are crucial for later updates, where the effect of a newly found document has to be determined, often after several years, and likely by a different contributor. • The fact that two timezones agree since 1970 has nothing to do with the fact that some timezones have changed their names, with the old names being kept as Links to the new names. Currently, however, Links representing one or both facts are kept in the same file backward, and cannot be distinguished. This leads to information loss and update anomalies: Currently, the file backward has a Link from Africa/Asmera to Africa/Nairobi -- the information that Asmera is an outdated spelling of Asmara can only be found in the file backzone. The name America/Virgin had been replaced by America/St_Thomas in version 95k, and this fact could be seen in the file backward until 2021a when this information was lost. It reappeared (in backzone) only in version 2021c. Keeping one type of information (spelling changes) in different locations (files backward or backzone) depending on an independent condition (that may even change over time) certainly causes unnecessary maintenance effort. While some of these points may sound like theoretical claims for normal forms as taught in computer science, my point here is only practical simplicity: each basic fact to be recorded in tzdb should have its obvious place where it is stored and where it can be looked up and updated; and updates of independent facts should be possible without mutual side effects. This appears to be a necessity for a collaborative project. Last Saturday, Paul Eggert has very nicely summarized the history and some of the guiding principles of tzdb. It is largely due to his immense work on the maintenance and evolvement of tzdb that the tzdb system was such a tremendous success in its first 30 years. As a means for the success over the next 30 years, I propose a simplification of the tzdb schema, so as to avoid the update anomalies described above, and thus decrease the maintenance burden, currently mainly shouldered by Paul. The information schema used in the fork produced by Stephen Colebourne is already much simpler, and it is apparently what is needed by several power users contributing to the widespread success of tzdb. Michael Deckers.

2 1

Kyiv not Kiev
by Petro Ord July 2, 2022

July 2, 2022

Hello, Please be informed that your database has an error in naming Ukrainian city Kyiv. It is provided in the tz database as 'Kiev'. In June 2019 the name *Kyiv* was officially adopted by the United States Board on Geographic Names as the only correct one. Please correct the mistake Thank you

18 66

Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d
by Peter Krefting July 1, 2022

July 1, 2022

Hi! I am creating timezone data for an embedded device, and with space as a premium I run zic with the -r parameter to cut off all time change information from before the software release date, as this is not relevant for the system. Since commit 5f06f9a3182d2c2942be1b678e4defa9c7400653 (included in 2021d), this causes the Etc/GMT+xx and Etc/GMT-xx timezones not to work, they always report GMT ("-00"): ~ # TZ=Europe/Oslo date Mon Mar 21 13:08:32 CET 2022 ~ # TZ=Europe/London date Mon Mar 21 12:08:36 GMT 2022 ~ # TZ=Etc/GMT+1 date Mon Mar 21 12:08:43 -00 2022 ~ # TZ=Etc/GMT+2 date Mon Mar 21 12:08:45 -00 2022 This is particularly severe for our devices since previous versions of our software only supported UTC offsets, and these are automatically updated to these GMT+xx and GMT-xx timezones on update, so many of our customers are expected to have these zones configured. We are running with "-r cutoff -b fat", where cutoff depends on the release date, and the embedded software currenlty is using GNU libc 2.20. Reverting 5f06f9a3182d2c2942be1b678e4defa9c7400653 fixes the issue for us, but is probably not the correct approach. -- \\// Peter - http://www.softwolves.pp.se/

3 6

Re: [tz] tz Digest, Vol 129, Issue 1
by Santoni Francis July 1, 2022

July 1, 2022

Hello for Iran and 1977 the effective change is only 20 october (UIT n°143 17.XI.1977) and not 23 september (UIT n°141 13.IX.1977) UIT is the Operational Bulletin of International Telecommunication Union Francis Santoni

3 2