- tz - lists.iana.org

Re: [tz] [IANA #1173666] Time zone change - Yukon Canada
by Andrew.Smith＠gov.yk.ca Sept. 30, 2020

Sept. 30, 2020

Good day. I work for the Government of Yukon in Canada. We are in the process of revising our definition of time to be permanently on UTC -7, no longer observing a twice-annual time change. I was on the hunt for authoritative standards related to time, and saw the IANA come up as caretaker of the time zone database, which appears to be relied on for software and systems. I am contacting you to see if there is any process beyond notification to making this adjustment in your TZ database, and perhaps to know if there are other agencies that should be aware of what Yukon is planning. From what I see now, TZ database names "America/Dawson", "America/Whitehorse" and "Canada/Yukon" would be affected by this change. Our regulation is not yet complete, so it is not law at this time and I am not looking for immediate change. We are aiming for finalization here by November 1, 2020. Hope to hear from you soon. Andrew Andrew G. Smith Intergovernmental Relations Executive Council Office Government of Yukon C: 867-335-6008 -----Original Message----- From: Amanda Baber via RT <iana-questions(a)iana.org> Sent: July 2, 2020 3:48 PM To: Andrew.Smith <Andrew.Smith(a)gov.yk.ca> Subject: [IANA #1173666] Time zone change - Yukon Canada Dear Andrew, Thank you for contacting us. IANA hosts the Time Zone Database, but the database is managed by the Time Zone Coordinator in conjunction with a mailing list. You can find find mailing list information here: https://www.iana.org/time-zones This document should have or point to much of the information you're looking for: https://data.iana.org/time-zones/tz-link.html As is noted at the link above, "If your government plans to change its time zone boundaries or daylight saving rules, inform tz(a)iana.org well in advance, as this will coordinate updates to many cell phones, computers, and other devices around the world. With less than a year's notice there is a good chance that some computer-based clocks will operate incorrectly after the change, due to delays in propagating updates to software and data. The shorter the notice, the more likely clock problems will arise; see https://imsva91-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%… for examples." Best regards, Amanda Baber Lead IANA Services Specialist On Thu Jul 02 22:20:44 2020, Andrew.Smith(a)gov.yk.ca wrote: > Good day. > > I work for the Government of Yukon in Canada. We are in the process of > revising our definition of time to be permanently on UTC -7, no longer > observing a twice-annual time change. > I was on the hunt for authoritative standards related to time, and saw > the IANA come up as caretaker of the time zone database, which appears > to be relied on for software and systems. I started with ISO 8601, but > couldn't see the full text to know if there are time zone standards > there. I am contacting you to see your TZ database is a widely adopted > and authoritative as it seems, to see if there is any process to > making this adjustment in your TZ database, and perhaps to know if > there are other agencies that should be aware of what Yukon is > planning. > From what I see now, TZ database names "America/Dawson", > "America/Whitehorse" and "Canada/Yukon" would be affected by this > change. > > Our regulation is not yet complete, so it is not law at this time and > I am not looking for immediate change. We are aiming for finalization > here by November 1, 2020. > Hope to hear from you soon. > > Andrew > > > [cid:image003.png@01D65084.40C16690] > > Andrew G. Smith > Intergovernmental Relations > Executive Council Office > C 867-335-6008 | Yukon.ca

10 23

Python PEP-615 release eminent
by Matt Johnson-Pint Sept. 21, 2020

Sept. 21, 2020

Just a heads up. Python 3.9.0 is scheduled for release in two weeks on 2020-10-05

3 4

Europe/Kyiv
by Ihor Romanyshyn Sept. 14, 2020

Sept. 14, 2020

Hi there! It's possible to add an alias "Europe/Kyiv" for russian name "Europe/Kiev"? For more information about this please read https://en.wikipedia.org/wiki/KyivNotKiev -- Ihor Romanyshyn Network Administrator *Avenga* 118b Antonovycha Str 79057 Lviv Ukraine office +380 67 670 5051 <+380676705051> mobile +380 93 957 5136 <+380939575136> mail ihor.romanyshyn(a)avenga.com www.avenga.com Avenga - Transforming Industries

2 1

looking for information about changing time zone
by Françoise Kerjouan Sept. 11, 2020

Sept. 11, 2020

Madam, Sir, Im living in New Caledonia; our local government is thinking about changing time zone (from UTC +11 to UTC +12). Could you please tell me how long a lead notice should be to be sure that the international community will get and process the information ? I understood that the ICAN TZ database is widely used, but I didnt catch if it is also used for international transports (by airports for example). Could you please tell me if it is the case? If not, whom should I ask for? Best regards, Françoise Kerjouan

5 6

Question] Regarding Asia/Yerevan timezone abbreviation
by Goun Lee Sept. 10, 2020

Sept. 10, 2020

Hi, I'm Goun from South Korea. I have a question regarding Asia/Yerevan timezone abbreviation When I checked the following line, https://github.com/eggert/tz/blob/master/asia#L127 it's written as 4:00 Armenia +04/+05 As far as I know, Armenia has no DST time, so the abbreviation should +04. isn't it? I'm just wondering if it's correct or not. best regards. Goun

2 1

DST on Twitter :-)
by Sergiusz Wolicki Sept. 9, 2020

Sept. 9, 2020

User Brent Terhune (@BrentTerhune) wrote at 9:55 PM on Sep 9: The guy who invented Daylight Saving was ahead of his time. Or behind, depending on which month it was. (https://twitter.com/BrentTerhune/status/1303784188584300545?s=03) -- Sergiusz

1 0

timezone DB distribution
by Juergen Naeckel Sept. 8, 2020

Sept. 8, 2020

Hey there, First of all, I would like to thank you. I have to implement something in JavaScript that uses timezones. However, I am using an older JS version that does not have the flexibility like today’s JS. So I was looking for a repository holding all current timezones and rules for it, rather then me, checking time and again how which timezone is configured 😉 This really could help me. Reading through the files, it sometimes made me chuckle and I was actually surprised how fluent timezones are handled. Changes almost every year… I would like to recommend some improvements. I know you have pretty stable release by now. I am aware that changes probably to the structure might affect a lot of people/projects. However… First of all, a tar.gz is Linux specific. True, you could install additional Windows software. But, that might not go well with customers of mine. I think a ZIP would be acceptable for both worlds. Since I was interested in the repository, I downloaded the “Data only distribution”. I found six files containing the TZ information. And I found 27 files, containing other stuff. Well, there might be three or four files in a grey zone (calendars, backlist…). But I definitely do not consider MAKEFILE and .awk file as part of a “data only distribution”. Maybe move them to a separate folder in the GZ file? Finally, I got one more recommendation/question. I had read the readme file but it didn’t explain the data I saw in the files. It took me a while to understand the concept of the data structure. Some info of what to see in the file, and how to read it would help. And I think the first line of the ZONE definition contains some inconsistency (maybe I still didn’t understand it correctly). Below is a screenshot. See the first line for the zones? It looks mismatched with the New York. The RULE and the [UNTIL] are probably in the wrong column. Format is probably missing. [cid:image002.png@01D674A5.27F71B60] Then I noticed that the open-end validity. For rules it is denoted as “max” and for zones it is just a <blank>. Could we get some consistency here? And finally here comes my question: In the rules, I see in the column several times denoted with a tailing “u” or “s”. I think I read on one occasion that the times are denoted in “standard time”. I do not recall anymore where that was. But regardless, 1. I don’t understand what that “denoted in standard time” would mean 2. I definitely have no clue would the tailing “u”: would imply. [cid:image003.png@01D674A6.99550F50] Can you shed some light on this? Thank you! Not only for an answer but also for researching and compiling this list. Juergen Juergen Naeckel PRINCIPAL ARCHITECT T 617 766 2381 | C 617 775 3874 naeckel(a)adobe.com [cid:image001.png@01D6749A.D7B33580]

14 36

Iceland stays put on time zone
by Paul Eggert Sept. 7, 2020

Sept. 7, 2020

After more than two years of discussion, Iceland's government decided not to move its time zone back to -01, where it was before daylight saving time was introduced. Currently Iceland is at +00, effectively permanent DST. Proponents of changing back had argued that DST has harmful effects on human health. To counteract DST's health effects, the government decided instead to launch an educational campaign to get Icelanders to sleep more. It is also considering monitoring children's sleep habits and starting school days later. See: Gréta Sigríður Einarsdóttir, Iceland’s Time Zone to Remain Unchanged. Iceland Review. 2020-09-01. https://www.icelandreview.com/sci-tech/icelands-time-zone-to-remain-unchang…

1 0

DST in the news
by Arthur David Olson Aug. 29, 2020

Aug. 29, 2020

"American Academy of Sleep Medicine calls for elimination of daylight saving time" https://aasm.org/american-academy-of-sleep-medicine-calls-for-elimination-o… (Use your browser's vertical scroll bar to move through the article while avoiding an obscuring popup.) Noted on @Twitter by @AASMorg and retweeted by Jef Poskanzer (@JefPosk): https://twitter.com/AASMorg/status/1299334700478201858 @dash dashado

7 9

[PROPOSED] * asia: Cite Barak 2020 on Israeli DST controversy.
by Paul Eggert Aug. 23, 2020

Aug. 23, 2020

--- asia | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/asia b/asia index 106efad..fff9a10 100644 --- a/asia +++ b/asia @@ -1699,6 +1699,10 @@ Zone Asia/Baghdad 2:57:40 - LMT 1890 # Israel +# For more info about the motivation for DST in Israel, see: +# Barak Y. Israel's Daylight Saving Time controversy. Israel Affairs. +# 2020-08-11. https://doi.org/10.1080/13537121.2020.1806564 + # From Ephraim Silverberg (2001-01-11): # # I coined "IST/IDT" circa 1988. Until then there were three -- 2.25.4

1 0

ta and VBA
by Marlon Rosenthal Aug. 22, 2020

Aug. 22, 2020

Hello there, I am working on a private research procedure where I would like to use your database. Unfortunately I am working in Excel/VBA and have not found any link or advice how to use it with VBA. I hope there is something and maybe you can help me with a link? Best regards, Marlon Marlon Rosenthal german voice-over [image: Logo] <http://www.sprecherprofi.de/> sprecherprofi | +49 163 6002666 | marlon(a)sprecherprofi.de [image: Banner] <http://www.sprecherprofi.de/>

2 1

XKCD Comic
by stevejones＠ontimezone.com Aug. 19, 2020

Aug. 19, 2020

While this comic neither represents the strength of the TZ infrastructure or the significant body of persons who contribute to and maintain it, I thought this still provided an amusing way to look at it: https://xkcd.com/2347/ Steve Jones

1 0

Change Request: Europe/Kiev to Europe/Kyiv
by Victor Perov Aug. 16, 2020

Aug. 16, 2020

Dear Sir/Madam, I hope this email finds you well. I'm writing to you with a request to accept proposed changes of correcting the spelling of capital of Ukraine Kyiv in the Time Zone Database. I've found previously closed PR with the same intention. It was about renaming Kyiv and other two cities of Ukraine: Uzhhorod and Zaporizhia. It was closed 4y ago with no changes applied. I am deeply sorry for comments left by their authors in that PR. Those messages were sounding offensive and I understand your decision of closing that PR with no decision made. I agree, 4y ago the usage of Kiev was much wider than nowadays, and believe you will find materials I attached to my PR meaningful. The link to PR I've brought to your attention: https://github.com/eggert/tz/pull/27 I have also attached a patch of the commit to the email. Looking forward to hearing from you. Kind regards, Viktor Perov

5 5

[PROPOSED 1/2] Minor editorial improvements for newstrftime.3
by Paul Eggert Aug. 15, 2020

Aug. 15, 2020

* newstrftime.3: Improve this a bit to have it match POSIX better. Resurrect the BSD manual’s phase-of-the-moon joke. --- newstrftime.3 | 103 ++++++++++++++++++++++++++++++++------------------ 1 file changed, 66 insertions(+), 37 deletions(-) diff --git a/newstrftime.3 b/newstrftime.3 index df38d1a..63842c7 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -50,12 +50,14 @@ strftime \- format date and time .B cc ... \-ltz .fi .SH DESCRIPTION -.ie '\(en'' .ds en \- -.el .ds en \(en .ie '\(lq'' .ds lq \&"\" .el .ds lq \(lq\" .ie '\(rq'' .ds rq \&"\" .el .ds rq \(rq\" +.de c +.ie \n(.g \f(CW\\$1\fP\\$2 +.el \\$1\\$2 +.. .de q \\$3\*(lq\\$1\*(rq\\$2 .. @@ -63,7 +65,7 @@ The .B strftime function formats the information from .I timeptr -into the buffer +into the array pointed to by .I buf according to the string pointed to by .IR format . @@ -72,24 +74,24 @@ The .I format string consists of zero or more conversion specifications and ordinary characters. -All ordinary characters are copied directly into the buffer. +All ordinary characters are copied directly into the array. A conversion specification consists of a percent sign .Ql % and one other character. .PP No more than .I maxsize -characters are placed into the array. -If the total number of resulting characters, including the terminating -null character, is not more than +bytes are placed into the array. +If the total number of resulting bytes, including the terminating +NUL character, is not more than .IR maxsize , .B strftime -returns the number of characters in the array, not counting the -terminating null. -Otherwise, zero is returned. +returns the number of bytes placed into the array, not counting the +terminating NUL. +Otherwise, zero is returned and the array contents are unspecified. .PP Each conversion specification is replaced by the characters as -follows which are then copied into the buffer. +follows which are then copied into the array. .TP %A is replaced by the locale's full weekday name. @@ -105,99 +107,122 @@ is replaced by the locale's abbreviated month name. .TP %C is replaced by the century (a year divided by 100 and truncated to an integer) -as a decimal number (00\*(en99). +as a decimal number [00,99]. .TP %c is replaced by the locale's appropriate date and time representation. .TP %D -is replaced by the date in the format %m/%d/%y. +is equivalent to +.c %m/%d/%y . .TP %d -is replaced by the day of the month as a decimal number (01\*(en31). +is replaced by the day of the month as a decimal number [01,31]. .TP %e -is replaced by the day of month as a decimal number (1\*(en31); +is replaced by the day of month as a decimal number [1,31]; single digits are preceded by a blank. .TP %F -is replaced by the date in the format %Y\*-%m\*-%d. +is equivalent to +.c %Y-%m-%d +(the ISO 8601 date format). .TP %G is replaced by the ISO 8601 year with century as a decimal number. +See also the +.c %V +conversion specification. .TP %g -is replaced by the ISO 8601 year without century as a decimal number (00\*(en99). +is replaced by the ISO 8601 year without century as a decimal number [00,99]. +This is the year that includes the greater part of the week. +(Monday as the first day of a week). +See also the +.c %V +conversion specification. .TP %H -is replaced by the hour (24-hour clock) as a decimal number (00\*(en23). +is replaced by the hour (24-hour clock) as a decimal number [00,23]. .TP %I -is replaced by the hour (12-hour clock) as a decimal number (01\*(en12). +is replaced by the hour (12-hour clock) as a decimal number [01,12]. .TP %j -is replaced by the day of the year as a decimal number (001\*(en366). +is replaced by the day of the year as a decimal number [001,366]. .TP %k -is replaced by the hour (24-hour clock) as a decimal number (0\*(en23); +is replaced by the hour (24-hour clock) as a decimal number [0,23]; single digits are preceded by a blank. .TP %l -is replaced by the hour (12-hour clock) as a decimal number (1\*(en12); +is replaced by the hour (12-hour clock) as a decimal number [1,12]; single digits are preceded by a blank. .TP %M -is replaced by the minute as a decimal number (00\*(en59). +is replaced by the minute as a decimal number [00,59]. .TP %m -is replaced by the month as a decimal number (01\*(en12). +is replaced by the month as a decimal number [01,12]. .TP %n is replaced by a newline. .TP %p -is replaced by the locale's equivalent of either AM or PM. +is replaced by the locale's equivalent of either +.q AM +or +.q PM . .TP %R -is replaced by the time in the format %H:%M. +is replaced by the time in the format +.c %H:%M . .TP %r is replaced by the locale's representation of 12-hour clock time using AM/PM notation. .TP %S -is replaced by the second as a decimal number (00\*(en60). +is replaced by the second as a decimal number [00,60]. +The range of +seconds is [00,60] instead of [00,59] to allow for the periodic occurrence +of leap seconds. .TP %s -is replaced by the number of seconds since the Epoch (see newctime(3)). +is replaced by the number of seconds since the Epoch (see +.BR ctime (3)). .TP %T -is replaced by the time in the format %H:%M:%S. +is replaced by the time in the format +.c %H:%M:%S . .TP %t is replaced by a tab. .TP %U is replaced by the week number of the year (Sunday as the first day of -the week) as a decimal number (00\*(en53). +the week) as a decimal number [00,53]. .TP %u is replaced by the weekday (Monday as the first day of the week) -as a decimal number (1\*(en7). +as a decimal number [1,7]. .TP %V is replaced by the week number of the year (Monday as the first day of -the week) as a decimal number (01\*(en53). If the week containing January +the week) as a decimal number [01,53]. If the week containing January 1 has four or more days in the new year, then it is week 1; otherwise it is week 53 of the previous year, and the next week is week 1. +The year is given by the +.c %G +conversion specification. .TP %W is replaced by the week number of the year (Monday as the first day of -the week) as a decimal number (00\*(en53). +the week) as a decimal number [00,53]. .TP %w is replaced by the weekday (Sunday as the first day of the week) -as a decimal number (0\*(en6). +as a decimal number [0,6]. .TP %X is replaced by the locale's appropriate time representation. @@ -209,7 +234,7 @@ is replaced by the locale's appropriate date representation. is replaced by the year with century as a decimal number. .TP %y -is replaced by the year without century as a decimal number (00\*(en99). +is replaced by the year without century as a decimal number [00,99]. .TP %Z is replaced by the time zone abbreviation, @@ -217,7 +242,7 @@ or by the empty string if this is not determinable. .TP %z is replaced by the offset from the Prime Meridian -in the format +HHMM or \*-HHMM as appropriate, +in the format +HHMM or \*-HHMM (ISO 8601) as appropriate, with positive values representing locations east of Greenwich, or by the empty string if this is not determinable. The numeric time zone abbreviation \*-0000 is used when the time is @@ -231,7 +256,9 @@ time zone abbreviation begins with is replaced by a single %. .TP %+ -is replaced by the date and time in date(1) format. +is replaced by the locale's date and time in +.BR date (1) +format. .SH SEE ALSO date(1), getenv(3), @@ -239,3 +266,5 @@ newctime(3), newtzset(3), time(2), tzfile(5) +.SH BUGS +There is no conversion specification for the phase of the moon. -- 2.17.1

4 15

tz database update on a publication & thank-you.
by Andrew Lyon Aug. 3, 2020

Aug. 3, 2020

Several months ago I posted queries about the tz database to this discussion list as I investigated a series of errors triggered in software used to order and report clinical laboratory tests in our hospital network. Our main software system uses universal time for date& time of birth a recently added peripheral system (based on Android OS, and Java Joda-time that relies on the tz database) that triggered the peripheral system to freeze every few weeks. Investigation revealed that there were 10 years (between 1935 and 1945) in the America/Regina tz time zone data where the transition to daylight saving time occurred at midnight on spring transition dates. If our hospital (which is in the America/Regina time zone) encountered patients born on one of those spring daylight savings time transitions dates 1935-1945, the system froze, because the hour of birth was usually unknown and was assigned to midnight local time by default, and midnight local time on those dates does not map back to universal time. A software patch was quickly developed by the software provider and this susceptibility is now avoided. I understand now that this type of situation is well known to members of this group. I want to pass on a 'thank-you' to the tz database community for their helpful messages as this case was investigated. A description of this investigation was published today in the Journal of Applied Laboratory Medicine: "No Lab Tests" When You Are Born in The Twilight Zone: A Clinical Informatics Case Report. [ https://pubmed.ncbi.nlm.nih.gov/32728691/ | https://pubmed.ncbi.nlm.nih.gov/32728691/ ] best wishes, Andrew Dr. A.W. Lyon Dept Pathology and Laboratory Medicine University of Saskatchewan, SK, Canada

8 8

[PATCH] Update Bahrain as per article in The National
by Paul Eggert July 25, 2020

July 25, 2020

* backzone (Asia/Bahrain): Adjust transitions before 1944 to match Ashleigh Stewart’s article in today’s The National (Abu Dhabi). --- backzone | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/backzone b/backzone index 91fa21d..7cf026d 100644 --- a/backzone +++ b/backzone @@ -459,7 +459,22 @@ Zone Asia/Aden 2:59:54 - LMT 1950 3:00 - +03 # Bahrain -Zone Asia/Bahrain 3:22:20 - LMT 1920 # Manamah +# +# From Paul Eggert (2020-07-22): +# Most of this data comes from: +# Stewart A. Why Gulf Standard Time is far from standard: the fascinating story +# behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. +# https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… +# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# others at +0323. Reginald George Alban, a British political agent based in +# Manama, worked to standardize this, and from 1941-07-20 Bahrain was at +# +0330. However, BOAC asked that clocks be moved to gain more light at day's +# end, so Bahrain switched to +04 on 1944-01-01. +# +# We don't know when companies chose +0330 or +0323 before 1940; for now +# assume that there was no real standard in Bahrain before 1941-07-20. +Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah + 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun 3:00 - +03 -- 2.17.1

4 4

Re: [tz] Fwd: DST changes in Hungary (full historical revision)
by Paul Eggert July 25, 2020

July 25, 2020

Thanks for those corrections. I installed the attached patch to the development database on GitHub. It's not exactly what you emailed me, but it should generate equivalent transitions. It'd help if we could list citations for the transitions; are URLs available for each decree etc. that you consulted? We could add them as comments. Thanks again.

9 33

[PROPOSED] * backzone: More commentary re 1940s Bahrain.
by Paul Eggert July 23, 2020

July 23, 2020

--- backzone | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/backzone b/backzone index 7cf026d..f2684b4 100644 --- a/backzone +++ b/backzone @@ -460,19 +460,31 @@ Zone Asia/Aden 2:59:54 - LMT 1950 # Bahrain # -# From Paul Eggert (2020-07-22): +# From Paul Eggert (2020-07-23): # Most of this data comes from: # Stewart A. Why Gulf Standard Time is far from standard: the fascinating story # behind the time zone's invention. The National (Abu Dhabi). 2020-07-22. # https://www.thenational.ae/arts-culture/why-gulf-standard-time-is-far-from-… -# Stewart writes that before 1940 some companies in Bahrain were at +0330 and +# Stewart writes that before 1941 some companies in Bahrain were at +0330 and # others at +0323. Reginald George Alban, a British political agent based in # Manama, worked to standardize this, and from 1941-07-20 Bahrain was at # +0330. However, BOAC asked that clocks be moved to gain more light at day's # end, so Bahrain switched to +04 on 1944-01-01. # -# We don't know when companies chose +0330 or +0323 before 1940; for now -# assume that there was no real standard in Bahrain before 1941-07-20. +# Re the 1941 transition, Stewart privately sent me this citation: +# "File 16/53 Enquiries Re: Calculation of Local Time", British Library: India +# Office Records and Private Papers, IOR/R/15/2/1564, in Qatar Digital Library +# https://www.qdl.qa/archive/81055/vdc_100000000282.0x00012b +# It says there was no real standard in Bahrain before 1941-07-20. +# +0330 was used by steamers of the British India Co, by Petroleum Concessions +# and by Cable & Wireless; +0323 was used by the Eastern Bank Ltd, BOAC, and +# Bahrein Petroleum (Bapco), and California Arabian Standard Oil Co (Casoc) +# adopted DST effective 1941-05-24. Alban suggested adopting DST, R.B. Coomb +# of C&W countersuggested +0330, and although C.A. Rodstrom of Casoc (formerly +# of Bapco) stated that Bahrain had formerly used +0330 before Bapco arrived +# but Bapco switched to +0323 because of "constant confusion", the consensus +# was +0330. The government adopted +0330 in 1941-07-20 and companies seem to +# have switched by 08-01. No time of day was given for the 1940s transitions. Zone Asia/Bahrain 3:22:20 - LMT 1941 Jul 20 # Manamah 3:30 - +0330 1944 Jan 1 4:00 - +04 1972 Jun -- 2.17.1

1 0

Re: [tz] A warning on the tzdb 2020a
by Paul Eggert July 9, 2020

July 9, 2020

On 7/8/20 2:22 PM, Matias Fonzo wrote: > ./zic -d '/usr/src/qi/build/package-tzdb/etc/zoneinfo-leaps' -L leapseconds > tzdata.zi > warning: "leapseconds", line 79: "#expires" is obsolescent; use "Expires" Yes, that's a known warning. You can silence the warning by removing the leapseconds file and then building with 'make EXPIRES_LINE=1'. See the Makefile for details. At some point in the not-too-distant future I plan to fix this by defaulting EXPIRES_LINE=1 in the Makefile; this will change the "#Expires" line to an "Expires" line in the distributed leapseconds file. In reviewing the EXPIRES_LINE=1 code I noticed that it put a wrong comment in its output, which I fixed by installing the attached. I also updated the expires line as noted in <https://mm.icann.org/pipermail/tz/2020-July/029165.html>.

1 0

[PATCH] No leap second on 2020-12-31
by Paul Eggert July 9, 2020

July 9, 2020

* leap-seconds.list: Update file from NIST, retrieved from ftp://ftp.nist.gov/pub/time/leap-seconds.list in ASCII mode. --- leap-seconds.list | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/leap-seconds.list b/leap-seconds.list index ac153da..e897a86 100644 --- a/leap-seconds.list +++ b/leap-seconds.list @@ -204,10 +204,10 @@ # current -- the update time stamp, the data and the name of the file # will not change. # -# Updated through IERS Bulletin C59 -# File expires on: 28 December 2020 +# Updated through IERS Bulletin C60 +# File expires on: 28 June 2021 # -#@ 3818102400 +#@ 3833827200 # 2272060800 10 # 1 Jan 1972 2287785600 11 # 1 Jul 1972 @@ -252,4 +252,4 @@ # the hash line is also ignored in the # computation. # -#h a1c168ae 27c79a7d 9dddcfc3 bcfe616b 2e2c44ea +#h 064356a8 39268b92 76e4d5ef 3e22fae1 0cca529c -- 2.17.1

1 0

Tim Parenti as backup TZ Coordinator?
by Paul Eggert July 9, 2020

July 9, 2020

Tim Parenti's recent emails to the list reminded me that I'd long been meaning to nominate him to be my backup as TZ Coordinator. We should have a backup in case I am no longer available due to retirement or whatever, not that I'm planning to retire any time soon. I would like to start by giving him commit privileges to the development repository on GitHub, so that his contributions can become part of releases more easily. Tim has been a longtime and substantial contributor to tzdb, as evidenced by his detailed and careful patches. Although he's mostly worked in the tzdata area, he's also proficient on the code side, as his recent patch proposals demonstrate. He and I have corresponded by email about this and he's indicated his willingness to take on the responsibility. I'd appreciate reactions to Tim's offer to be backup; please respond within the next week.

12 13

North Vietnam 1970 to 1975 - Asia/Hanoi belongs into main file
by Alois Treindl July 2, 2020

July 2, 2020

(Corrected subject line) The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

6 14

Re: [tz] Mirmalek on Martian timekeeping
by Paul Eggert June 30, 2020

June 30, 2020

On 6/30/20 2:00 AM, BASTIAN Michelle wrote: > I wondered if you had come across this ethnography of mars working time https://brill.com/view/journals/kron/8/2/article-p159_7.xml?language=en No, I wasn't familiar with Mirmalek's work. I see she turned it into a book published in March. Thanks for the heads-up. I updated theory.html's discussion of Martian timekeeping based on the info you sent, and installed the attached patch. This patch also changes some tenses in the text, as the Mars Exploration Rover mission's second rover bit the dust in 2018 (literally: communications cut off during a planetwide dust storm).

1 0

re SPDX, I'll do the work, if you'll use the tag
by Mark Atwood June 30, 2020

June 30, 2020

I was tagged in to this list because of the discussion about SPDX license tagging. I sit on the SPDX committee (which doesn't mean much, it's similar to an IETF WG, in that anyone who joins the list, joins the calls, and then does needed work is "on the committee"). It may be useful to have an SPDX tag for the TZ database data files. The SPDX makes nearly zero legal assessment about a license. Applying an SPDX tag to an existing project is intended to document reality in a machine readable way, it is not intended to change reality. Having an SPDX tag is mostly for the benefit of systems and companies who are trying to be scrupulously correct when complying with open source licenses. When the SPDX evaluates a license, the things looked for are "does/will it have real users?", "does it have a stable enough text that the matching tools can correctly identify it?", and "is it for content intended for mostly uncontrolled distribution?". We very much do not get into all the arguments about "is this well defined in europe", "is this a license or a public domain declaration", "is copyright even appropriate", "copyleft is theft", etc etc etc. We don't practice law, and we don't want to dictate policy, we just id licenses for people who just want to know they are doing the right thing when using your files, and make suggestions for projects that want to write a policy about it. Looking at the TZ database history, it has a very long history with lots of contributors, its mostly just a collection of facts, it appears to be a public domain declaration, that started out kind of adhoc. Using one of the existing PD declarations in the SPDX database would not be appropriate, because of the need to get the past contributors to assent, lots of work for no value. What does make sense is creating a new tag, something like "TZ-PD". Then you can start putting "# SDPX-License-Identifier: TZ-PD" in your database text source file, and make life easier for a bunch of people who just want to do the right thing with your data. To repeat, adding that SPDX license tag of a new identifer to id an existing stable in the field declaration, like this, does not change any legal obligations or expose anyone to any new legal risks. It's just a machine readable way of saying what's already been said about the copyright status of the TZ database. So, I'm willing to volunteer to do that lift for the TZ community, if you are willing to use the resulting id tag. What say you? ..m Mark Atwood <mark.atwood(a)gmail.com> https://keybase.io/fallenpegasus +1-206-604-2198

4 3

North Vietnam 1970 to 1970 - Asia/Hanoi belongs into main file
by Alois Treindl June 28, 2020

June 28, 2020

The backzone file contains the zone Asia/Hanoi It should go into the main file for Asia. There exists no doubt that in all of what was North Vietnam between at least 1970 and 1975 the timezone was 7h east, and not 8h east as in South Vietnam. There may be unclear borders, but most of North Vietnam, including its capital, was not unclear at all. I find it a discrimination of former North Vietnam to not have it represented correctly, at least for the post-1970 period. What Paul Eggert writes in the comments is a poor excuse. From Paul Eggert (2019-02-19): # # The Ho Chi Minh entry suffices for most purposes as it agrees with all of # Vietnam since 1975-06-13. Presumably clocks often changed in south Vietnam # in the early 1970s as locations changed hands during the war; however the # details are unknown and would likely be too voluminous for this database. # # For timestamps in north Vietnam back to 1970 (the tzdb cutoff), # use Asia/Bangkok; see the VN entries in the file zone1970.tab. # For timestamps before 1970, see Asia/Hanoi in the file 'backzone'.

1 0