- tz - lists.iana.org

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