- tz - lists.iana.org

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

[PROPOSED] Refactor by using max and min macros
by Paul Eggert July 1, 2022

July 1, 2022

* localtime.c (SMALLEST, BIGGEST): Remove. All uses replaced by min and max. * private.h (max, min): New macros. * zdump.c (main): * zic.c (growalloc, timerange_option): Prefer max and min to doing it by hand. --- localtime.c | 17 ++++++----------- private.h | 5 +++++ zdump.c | 2 +- zic.c | 6 +++--- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/localtime.c b/localtime.c index 8644aa6..3db7821 100644 --- a/localtime.c +++ b/localtime.c @@ -102,9 +102,6 @@ struct lsinfo { /* leap second information */ int_fast32_t ls_corr; /* correction to apply */ }; -#define SMALLEST(a, b) (((a) < (b)) ? (a) : (b)) -#define BIGGEST(a, b) (((a) > (b)) ? (a) : (b)) - /* This abbreviation means local time is unspecified. */ static char const UNSPEC[] = "-00"; @@ -112,7 +109,7 @@ static char const UNSPEC[] = "-00"; This needs to be at least 1 for null termination in case the input data isn't properly terminated, and it also needs to be big enough for ttunspecified to work without crashing. */ -enum { CHARS_EXTRA = BIGGEST(sizeof UNSPEC, 2) - 1 }; +enum { CHARS_EXTRA = max(sizeof UNSPEC, 2) - 1 }; #ifdef TZNAME_MAX #define MY_TZNAME_MAX TZNAME_MAX @@ -131,9 +128,8 @@ struct state { time_t ats[TZ_MAX_TIMES]; unsigned char types[TZ_MAX_TIMES]; struct ttinfo ttis[TZ_MAX_TYPES]; - char chars[BIGGEST(BIGGEST(TZ_MAX_CHARS + CHARS_EXTRA, - sizeof gmt), - (2 * (MY_TZNAME_MAX + 1)))]; + char chars[max(max(TZ_MAX_CHARS + CHARS_EXTRA, sizeof gmt), + 2 * (MY_TZNAME_MAX + 1))]; struct lsinfo lsis[TZ_MAX_LEAPS]; /* The time type to use for early times or if no transitions. @@ -394,8 +390,7 @@ union local_storage { } u; /* The file name to be opened. */ - char fullname[BIGGEST(sizeof(struct file_analysis), - sizeof tzdirslash + 1024)]; + char fullname[max(sizeof(struct file_analysis), sizeof tzdirslash + 1024)]; }; /* Load tz data from the file named NAME into *SP. Read extended @@ -2086,10 +2081,10 @@ time2sub(struct tm *const tmp, && (yourtm.TM_GMTOFF < 0 ? (-SECSPERDAY <= yourtm.TM_GMTOFF && (mytm.TM_GMTOFF <= - (SMALLEST(INT_FAST32_MAX, LONG_MAX) + (min(INT_FAST32_MAX, LONG_MAX) + yourtm.TM_GMTOFF))) : (yourtm.TM_GMTOFF <= SECSPERDAY - && ((BIGGEST(INT_FAST32_MIN, LONG_MIN) + && ((max(INT_FAST32_MIN, LONG_MIN) + yourtm.TM_GMTOFF) <= mytm.TM_GMTOFF)))) { /* MYTM matches YOURTM except with the wrong UT offset. diff --git a/private.h b/private.h index e8c0942..b083c1b 100644 --- a/private.h +++ b/private.h @@ -632,6 +632,11 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TYPE_SIGNED(type) (((type) -1) < 0) #define TWOS_COMPLEMENT(t) ((t) ~ (t) 0 < 0) +/* Minimum and maximum of two values. Use lower case to avoid + naming clashes with standard include files. */ +#define max(a, b) ((a) > (b) ? (a) : (b)) +#define min(a, b) ((a) < (b) ? (a) : (b)) + /* Max and min values of the integer type T, of which only the bottom B bits are used, and where the highest-order used bit is considered to be a sign bit if T is signed. */ diff --git a/zdump.c b/zdump.c index 8b6788a..b10f574 100644 --- a/zdump.c +++ b/zdump.c @@ -548,7 +548,7 @@ main(int argc, char *argv[]) for (i = optind; i < argc; i++) { size_t arglen = strlen(argv[i]); if (longest < arglen) - longest = arglen < INT_MAX ? arglen : INT_MAX; + longest = min(arglen, INT_MAX); } for (i = optind; i < argc; ++i) { diff --git a/zic.c b/zic.c index 436677f..c0ff561 100644 --- a/zic.c +++ b/zic.c @@ -488,7 +488,7 @@ growalloc(void *ptr, size_t itemsize, ptrdiff_t nitems, ptrdiff_t *nitems_alloc) return ptr; else { ptrdiff_t nitems_max = PTRDIFF_MAX - WORK_AROUND_QTBUG_53071; - ptrdiff_t amax = nitems_max < SIZE_MAX ? nitems_max : SIZE_MAX; + ptrdiff_t amax = min(nitems_max, SIZE_MAX); if ((amax - 1) / 3 * 2 < *nitems_alloc) memory_exhausted(_("integer overflow")); *nitems_alloc += (*nitems_alloc >> 1) + 1; @@ -707,8 +707,8 @@ timerange_option(char *timerange) } if (*hi_end || hi < lo || max_time < lo || hi < min_time) return false; - lo_time = lo < min_time ? min_time : lo; - hi_time = max_time < hi ? max_time : hi; + lo_time = max(lo, min_time); + hi_time = min(hi, max_time); return true; } -- 2.36.1

2 1

[PROPOSED] Upgrade GCC_DEBUG_FLAGS to GCC 12
by Paul Eggert June 30, 2022

June 30, 2022

* Makefile (GCC_DEBUG_FLAGS): Add -Wbidi-chars=any,ucn and -Wuse-after-free=3, from GCC 12. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 56c4404..cbf5b96 100644 --- a/Makefile +++ b/Makefile @@ -264,7 +264,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ $(GCC_INSTRUMENT) \ -Wall -Wextra \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ - -Wbad-function-cast -Wcast-align=strict -Wdate-time \ + -Wbad-function-cast -Wbidi-chars=any,ucn -Wcast-align=strict -Wdate-time \ -Wdeclaration-after-statement -Wdouble-promotion \ -Wduplicated-branches -Wduplicated-cond \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ @@ -278,7 +278,7 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ - -Wtrampolines -Wundef -Wuninitialized -Wunused-macros \ + -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ -Wno-type-limits -Wno-unused-parameter -- 2.36.1

1 0

Correct time zone name
by Danylo Moshenskyi June 28, 2022

June 28, 2022

Hello! It's the perfect time to change officially "Europe/Kiev" to "Europe/Kyiv". Please check this post, Ukrainians support and need it so much: https://www.linkedin.com/posts/activity-6945658723713355776-NKJm

3 3

Ukraine time zone error
by Євген Доманський June 27, 2022

June 27, 2022

Dear All It has been 19 170 days since IANA time zone database has an error for Ukraine time zone. Be brave to support Ukraine in the war against russia and correct the mistake as quickly as possible. Thank you *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

1 0

Re: [tz] Europe/Kiev update for 1992-1995
by Doug Ewell June 26, 2022

June 26, 2022

Євген Доманський wrote: > 'Kyiv' has been used word-wide as the only correct Latin spelling of > Ukrainian city since the V century. 'Kiev' was only used in soviet > union and russia for a relatively small period of time. > Here is a example of the book written in 1570 - see KYIV You accidentally attached a picture of a book written in Greek, in the Greek script. I'm sure you meant to attach one that had something to do with English and the Latin script. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

2 3

Error in Ukraine time zone
by Євген Доманський June 26, 2022

June 26, 2022

Dear All It has been 19 169 days since IANA time zone database has an error for Ukraine time zone. Be brave to support Ukraine in the war against russia and correct the mistake as quickly as possible. Thank you *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

1 0

Kyiv not Kiev error
by Євген Доманський June 24, 2022

June 24, 2022

Dear All There is an error in name of the capital city of Ukraine - Kiev ('Київ' in Ukrainian language). Kiev is the transliteration of the city name from Russian language. The only correct transliteration is Kyiv. Please update the name. Best regards. *Yevhen Domanskyi* *Study Coordinator* Department of Oncology and Medical Radiology Dnipro State Medical University 31, Blyzhnya Str., Dnipro, 49102, Ukraine *Mobile*: +380 93 060 26 92 *e-mail: *dom.eugene(a)gmail.com Website: http://www.sitetv.net/ <http:/www.sitetv.net/>

11 26

Change Request: Europe/Kiev to Europe/Kyiv
by Oleksandr Leskiv June 23, 2022

June 23, 2022

The history of timezones has some existing cases where a specific timezone has been renamed. For example, the *Asia/Calcutta* timezone has been deemed obsolete and replaced by *Asia/Kolkata*. In Ukraine, according to international standards, there is a timezone called *Europe/Kiev*. The capital of Ukraine is officially and internationally should be spelled as "Kyiv". "Kiev" is an incorrect version that emerged a long time before the Soviet Union collapsed in 1991. We have a really large community of programmers that would like to start the process of renaming the Europe/Kiev timezone to Europe/Kyiv. We understand that it will take a long time for everybody to transition, but it has to be done in the long term. Sincerely, Oleksandr. TakeUsEat.

7 10

time zone boundaries contributing to higher traffic fatalities
by BASTIAN Michelle June 13, 2022

June 13, 2022

Hi all, I thought you might be interested in this recent paper on time zone boundaries and links with traffic fatalities - just published in Time & Society https://journals.sagepub.com/doi/full/10.1177/0961463X221104675 Living in the wrong time zone: Elevated risk of traffic fatalities in eccentric time localities Jeffery Gentry, Jayson Evaniuck, Thanchira Suriyamongkol, Ivana Mali Abstract Chronobiology research has uncovered a host of maladies linked to social jetlag (SJL), the sleep-disrupting disconnect between solar time and social time. This interdisciplinary study applies chronobiology theory to the potential effect of misaligned time zones on motor-vehicle deaths. In the U.S. 53 million residents live in counties located outside their official time zones' standard 15° span of longitude, based on degrees west of the prime meridian. We refer to these counties as eccentric time localities (ETLs), all of which lie west of their time zones' standard western border in the U.S. In contrast, counties within 7.5° of their time zone's standard geographic center are what we call solar zones. Solar zones do not vary more than 30 minutes from true solar time. ETL residents are forced to rise before dawn, possibly restricting their sleep-time and suppressing both morning and evening zeitgebers that would support their circadian entrainment. Hypothesizing that living in ETLs amplifies social jetlag, data on 417,399 traffic fatalities in the U.S. between 2006 and 2017 from the Fatality Analysis Reporting System (FARS) census were analyzed via GIS mapping and population-data statistics. Road fatalities among residents of solar zones were compared to those living in ETLs within the same official time zone. ETL residents across the U.S. indicated 21.8% higher fatality-rates than solar residents, with a mean of 1286 additional (i.e., unexpected) deaths-per-year. Results support circadian entrainment theory and are consistent with the SJL construct. The socio-political ramifications of these findings are discussed, as well as the subject of best practices when analyzing whole-population data. The authors conclude that the unquestioned rhetoric of time-zone boundaries should be reconsidered in social policy. Best, Michelle. --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh Mid-Career Fellow, Independent Social Research Foundation (Project info<https://www.isrf.org/fellows-projects/michelle-bastian/>) (2021-2022) Associate Professor II, Oslo School of Environmental Humanities, University of Oslo (2022-2024) Level 1, Room 303B, The Maltings | Minto House, 20-22 Chambers Street, Edinburgh, EH1 1JZ | 0131 651 5779 Work hours: I normally work 8am-4pm M-F. 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.

1 0

Invalid tm handling in %s pattern in strftime
by Almaz Mingaleev June 7, 2022

June 7, 2022

Hi Paul, https://github.com/eggert/tz/commit/8b238ec54c09556eb2aa405c1741eedfd12c4a8… added validation of tm argument. I wonder why localtime_r call is done: 1) According to the man page mktime sets errno if tm is invalid. Why is it not safe to just check errno value (saving and restoring it if needed)? 2) man page says that in error case mktime "returns (time_t) -1 and does not alter the members of the broken-down time structure". Wouldn't it be enough to check that tm.tm_yday is >= 0? Thanks, Almaz

4 11

Subject: Re: Change Turkey to Turkiye or not?
by nadir altinbas June 7, 2022

June 7, 2022

@ Topic 4. Re: Change Turkey to Turkiye or not? (Ian Abbott) i am resident in Istanbul, Istanbul is a city where a bridge of between Europe and Asia? most of the part of istanbul city is in Europe side. Telephony numbering coding system for PBX Europe is 0212 and Asia 0216 begins. Turkey -Turkiye- Turquie (Tr) name can be positined name as it Tr /Turkiye-Istanbul (Europe -Asia) ....... This is my idea. regards , nadir ALTINBAS nadiraltinbas(a)yahoo.com n.altinbas

1 0

Change Turkey to Turkiye or not?
by 柳芯宇 June 7, 2022

June 7, 2022

In some of the tz files, I found several mentions of "Turkey", this could be confusing since in my dictionaries, Turkey points to a food made by chicken, rather than a country. As recently UN and NATO suggests, I think it would be better and more representative to use Turkiye instead of Turkey, as we shound't setup times for just foods, right?

8 8

Re: [tz] Change Turkey to Turkiye or not?
by Doug Ewell June 6, 2022

June 6, 2022

柳芯宇 wrote: > In some of the tz files, I found several mentions of "Turkey", this > could be confusing since in my dictionaries, Turkey points to a food > made by chicken, rather than a country. I checked with a few turkeys (the bird) and they objected loudly to the notion that they are actually chickens. All joking aside: 1. The country has been known in English as "Turkey" for centuries, and although this has certainly given rise to some jokes, no one is genuinely confused when the word is used in context. 2. The identifier in the tz database which has by far the greatest visibility and relevance to users is "Europe/Istanbul", which avoids the issue altogether. 3. The rule name "Turkey" is comparatively invisible to most users, and there does not seem to be any mechanism for changing rule names, as there is for zone identifiers. 4. Any other mentions, such as in comments, can be changed freely, but there seems little point in doing so, at least at this time. > As recently UN and NATO suggests, I think it would be better and more > representative to use Turkiye instead of Turkey, as we shound't setup > times for just foods, right? "Turkiye" is not the name of the country in any language; the Turkish name is spelled "Türkiye" with diaeresis. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org

3 3

Historical data for Iran
by Roozbeh Pournader June 6, 2022

June 6, 2022

Hi, The timezone database currently lists Iran switching to standard time in 1946. I've been doing some research on the history of the adoption of standard time by Iran, and while it's very hard to find much, I found that the correct date is actually 1935. Here's an order from the Cabinet to the rest of the government to switch to Tehran time, which is mentioned to be already at +03:30: https://qavanin.ir/Law/TreeText/180138 Just in case that goes away, I also saved a copy at archive.org: https://web.archive.org/web/20220530111940/https://qavanin.ir/Law/TreeText/… Here's my translation: "Circular on Matching the Hours of Governmental and Official Circles in Provinces Approved 1314/03/22 [=1935-06-13] According to the ruling of the Honorable Cabinet, it is ordered that from now on in all internal provinces of the country, governmental and official circles set their time to match Tehran time (three hours and half before Greenwich). It is required to mind the above order. For Minister of Judiciary, Dr Matin-Daftari" Now, I still haven't found out when Tehran itself switched to +03:30 (let's assume some time earlier in 1935), but it is clear that standard time in Iran started on 1935-06-13 and not 1946. Thanks, Roozbeh

4 7

Yet more historical data for Iran
by Roozbeh Pournader June 2, 2022

June 2, 2022

Yet another discovery, which clarifies what happened in 1977 and 1978 in Iran. This is from Kayhan newspaper, one of the major Iranian newspapers, from March 20, 1978, page 2: "Pull the clocks 60 minutes forward As we informed before, from the fourth day of the month Farvardin of the new year [=1978-03-24], clocks will be pulled forward, and people's daily work and life program will start one hour earlier than the current program. On the 1st day of the month Farvardin of this year [=1977-03-21], they had pulled the clocks forward by one hour, but in the month of Mehr [=1977-09-23], the clocks were pulled back by 30 minutes. In this way, from the 4th day of the month Farvardin, clocks will be ahead of the previous years by one hour and a half. According to the new program, during the night of 4th of Farvardin, when the midnight, meaning 24 o'clock is announced, the hands of the clock must be pulled forward by one hour and thus consider midnight 1 o'clock in the forenoon." This implies that in September 1977, when the daylight savings time was done with, Iran didn't go back to +03:30, but immediately to +04:00. I'm still trying to figure out when exactly did Iran go back from +4:00 to +03:30. I'll report back when I find it. Based on the time of true noon announced in newspapers of the time, I've triangulated it to some time between 1978-11-05 and 1979-01-15, but it looks like major Iranian newspapers were stopped from publishing during most of that time period, so I can't figure out more using this method. For now, two changes are needed in tzdata, first is the start of daylight saving in 1978, the other the switch to +4:00/+5:00, which is currently listed as Nov 1977, but should change to exactly the end of daylight saving time in 1977. Thanks again, Roozbeh

2 1

End date of daylight saving in Iran in 1978
by Roozbeh Pournader June 1, 2022

June 1, 2022

I just found the date daylight savings ended in Iran in 1978. This is from the major Iranian newspaper Ettela'at, dated 1968-08-03, page 32. It looks like they decided to get the clocks back to +4:00 just in time for Ramadan that year: "Tomorrow Night, Pull the Clocks Back by One Hour At 1 o'clock in the forenoon of Saturday 14 Mordad [=1978-08-05], the clocks will be pulled one hour back and instead of 1 o'clock in the forenoon, Radio Iran will announce 24 o'clock. This decision was made in the Cabinet of Ministers meeting of 25 Tir [=1978-07-16], [...] At the beginning of the year 2537 [=March 1978: Iran was using a different year number for a few years then, based on the Coronation of Cyrus the Great], the country's official time was pulled forward by one hour and now the official time is one hour and a half ahead compared to last year, because in Farvardin of last year [=March 1977], the official time was pulled forward one hour and this continued until the second half of last year [=September 1977] until in the second half of last year the official time was pulled back half an hour and that half hour still remains." This matches the time of the true noon published in the newspapers, as they clearly go from +05:00 to +04:00 after that date (which happened during a long weekend in Iran). This means tzdata needs to fix the end of daylight saving in Iran for 1978 from October 20 to August 5. Thanks again, Roozbeh

1 0