August 2020 - tz - lists.iana.org

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson 18 Mar '22

18 Mar '22

I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > Thanks for bringing that to the mailing list (if I could shut off GitHub > pull requests I would). Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. https://github.com/eggert/tz/pulls?q=kiev Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. -- jhawk(a)alum.mit.edu John Hawkinson

10 13

Italy April 1944 discrepancy between comment and data
by Alois Treindl 05 Oct '21

05 Oct '21

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

FW: [Ext] The TZ Coordination
by Naela Sarras 02 Apr '21

02 Apr '21

Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf <afaf(a)anrt.ma> Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras <naela.sarras(a)iana.org> Cc: BENLEMLIH Hamida <benlemlih(a)anrt.ma> Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg@01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.

9 16

DST changes in Hungary (full historical revision)
by Nyáry Géza 12 Oct '20

12 Oct '20

Dear Paul! I examined it all of the Hungary daylight saving time changes. More differences I found what I repaired and I prepared it it source file, which I attach to this letter. I used Library Hungarica online database as a source, where from scanned contemporary ministerial decrees, instructions, newspapers and from other documents it was possible to find the time of the changes concerning the years. https://library.hungaricana.hu I checked the modified changes many times and I considered it right. If it's possible, I ask the exchange the attached modified Hungarian section in global database! Thank you very much! Bets regards, Géza Nyáry

5 11

Removing systemv, pacificnew, Rule TYPEs, zic -y
by Tim Parenti 04 Oct '20

04 Oct '20

I noticed recently that the systemv file, which adapted a subset of North American zones with limited rulesets to old versions of System V, has had all its once-useful bits commented out since 2005p. Looking back at list archives, even discussion at the time argued that the file wasn't really needed then. The attached proposed patch 0001 removes this obsolete file and its references. Of course, I was only looking at systemv in the first place because I'd also recalled that we're still distributing the pacificnew file, which has caused some confusion every so often and has likewise generally outlived its usefulness. This led me to the related file yearistype.sh, which is also unused, except as a default script to pass to the Makefile to process the TYPE field of Rule lines. Given that the TYPE field hasn't been used by tzdata since 2000f and has been more formally deprecated since 2015f, the whole unused feature is ripe for "spring cleaning". The attached proposed patch 0002 completely drops support for the TYPE field (marking it reserved for compatibility purposes) and causes non-trivial use of the field or use of zic's -y option to error (instead of warning as it has since 2017c). It also removes the pacificnew and yearistype.sh files that are no longer needed and updates documentation accordingly. I don't presently foresee any need to repurpose the nullified field down the road, but this is the next step in allowing us to "reclaim" it in the event that such a need should arise in the future. -- Tim Parenti

3 3

Updating zic.c to further match Link line field names
by Tim Parenti 03 Oct '20

03 Oct '20

In working on my latest proposed patch, I also noticed an outdated error message in zic.c which referred to the FROM field of a Link line. We had updated these field names in comments and documentation in release 2014g to be more descriptive and readily understandable like the parameters of 'ln': https://github.com/eggert/tz/commit/78e3924ea43079a0f3333677a728e0f0ed679cd3 The attached proposed patch further updates the zic.c code to more consistently use these new names throughout. This mostly affects the naming of parameters and locals, but a few macros and struct fields are also updated for consistency. -- Tim Parenti

1 1

Re: [tz] [IANA #1173666] Time zone change - Yukon Canada
by Andrew.Smith＠gov.yk.ca 30 Sep '20

30 Sep '20

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

timezone DB distribution
by Juergen Naeckel 08 Sep '20

08 Sep '20

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

DST in the news
by Arthur David Olson 29 Aug '20

29 Aug '20

"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 23 Aug '20

23 Aug '20

--- 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 21 Aug '20

21 Aug '20

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 19 Aug '20

19 Aug '20

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 16 Aug '20

16 Aug '20

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 15 Aug '20

15 Aug '20

* 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 03 Aug '20

03 Aug '20

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