- tz - lists.iana.org

Hard copy of TZdata2023?
by natyaveda Oct. 22, 2023

Oct. 22, 2023

Hey, are you aware of any printable or hard copy (paper) publications of your Time-Zone database in a complete or semi-complete form? Perhaps this has been produced by someone in the astrology community? I'm basically looking to see if its possible to get the rights to include parts of such a publication in a publication of my own. I doubt one exists that includes all the info for every city in the world in a single publication, but I'm looking to see if it does and how large it might be. What I have in mind is something that lists information pretty much exactly as its presented in the tables for the "Detailed time zone and clock changes" available on timeanddate.com (minus everything outside the tables): https://www.timeanddate.com/time/zone/canada/vancouver Thanks for any info you can provide! -James Foyle

8 19

[man]: Bullet lists
by Alejandro Colomar Oct. 22, 2023

Oct. 22, 2023

Hi Paul, I have a small suggestion for formatting of manual pages. Recently, I made lists uniform in the Linux man-pages project, and set some rules for them. See man-pages(7): Lists There are different kinds of lists: ... Bullet lists Elements are preceded by bullet symbols (\[bu]). Anything that doesn’t fit elsewhere is usually covered by this type of list. ... There should always be exactly 2 spaces between the list symbol and the elements. This doesn’t apply to "tagged paragraphs", which use the de‐ fault indentation rules. I guess using '\[bu]' (or '\(bu') might not be appropriate for the tz project, as it may be less portable to old systems, but the 2 spaces between the bullet (the '*' in your case) and the text would be useful. It better distinguishes text from bullets, in the few cases where it may be ambiguous (I didn't check if any may be ambiguous in the tz project). The change would be to use '.IP * 3' instead of '.IP * 2'. 3 is for the width of '*' +2. Would you be interested in such a change? Thanks, Alex -- <https://www.alejandro-colomar.es/>

2 3

[PROPOSED] Document GMT0 and posixrules better
by Paul Eggert Oct. 22, 2023

Oct. 22, 2023

Document the role of /usr/share/zoneinfo/GMT0. Also, improve the documentation for /usr/share/zoneinfo/posixrules. --- date.1 | 14 +++++--------- newctime.3 | 16 ++++++---------- newtzset.3 | 44 +++++++++++++++++++++++++------------------- zic.8 | 12 ++++++------ 4 files changed, 42 insertions(+), 44 deletions(-) diff --git a/date.1 b/date.1 index e8107212..01907bc7 100644 --- a/date.1 +++ b/date.1 @@ -154,15 +154,11 @@ hexadecimal (leading 0x), preceded by an optional sign. .br /usr/lib/locale/\f2L\fP/LC_TIME description of time locale \f2L\fP .br -/usr/share/zoneinfo timezone information directory +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. diff --git a/newctime.3 b/newctime.3 index 05bb7dea..3b54d4ad 100644 --- a/newctime.3 +++ b/newctime.3 @@ -292,20 +292,16 @@ will continue to exist in this form in future releases of this code. .SH FILES .ta \w'/usr/share/zoneinfo/posixrules\0\0'u -/usr/share/zoneinfo timezone information directory +/etc/localtime local timezone file .br -/usr/share/zoneinfo/localtime local timezone file +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. .SH SEE ALSO getenv(3), newstrftime(3), diff --git a/newtzset.3 b/newtzset.3 index 78b6b6ce..80617cd7 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -306,21 +306,31 @@ The abbreviations for standard and daylight saving time are and .q "\*-02". .PP -If no -.I rule -is present in -.BR TZ , -the rules specified -by the +If +.B TZ +specifies daylight saving time but does not specify a +.IR rule , +and the optional .BR tzfile (5)-format file .B posixrules -in the system time conversion information directory are used, with the -standard and daylight saving time offsets from UT replaced by those specified by -the +is present in the system time conversion information directory, the +rules in +.B posixrules +are used, with the +.B posixrules +standard and daylight saving time offsets from UT +replaced by those specified by the .I offset values in .BR TZ . +However, the +.B posixrules +file is obsolete: if it is present it is only for backward compatibility, +and it does not work reliably. +Therefore, applications that specify a +.B TZ +string with daylight saving time should specify rules explicitly. .PP For compatibility with System V Release 3.1, a semicolon .RB ( ; ) @@ -329,20 +339,16 @@ may be used to separate the from the rest of the specification. .SH FILES .ta \w'/usr/share/zoneinfo/posixrules\0\0'u -/usr/share/zoneinfo timezone information directory +/etc/localtime local timezone file .br -/usr/share/zoneinfo/localtime local timezone file +/usr/share/zoneinfo timezone directory .br -/usr/share/zoneinfo/posixrules default DST rules (obsolete, - and can cause bugs if present) +/usr/share/zoneinfo/posixrules default DST rules (obsolete) .br /usr/share/zoneinfo/GMT for UTC leap seconds -.sp -If -.B /usr/share/zoneinfo/GMT -is absent, -UTC leap seconds are loaded from -.BR /usr/share/zoneinfo/posixrules . +.PP +If /usr/share/zoneinfo/GMT is absent, +UTC leap seconds are loaded from /usr/share/zoneinfo/GMT0 if present. .SH SEE ALSO getenv(3), newctime(3), diff --git a/zic.8 b/zic.8 index c467efef..6bcef7ae 100644 --- a/zic.8 +++ b/zic.8 @@ -121,6 +121,12 @@ will act as if the input contained a link line of the form .ti +.5i Link \fItimezone\fP posixrules .sp +If +.I timezone +is +.q "\*-" +(the default), any already-existing link is removed. +.sp Unless .I timezone is .q "\*-" , @@ -131,12 +137,6 @@ and it should not be combined with if .IR timezone 's transitions are at standard time or Universal Time (UT) instead of local time. -.sp -If -.I timezone -is -.BR \*- , -any already-existing link is removed. .TP .BR "\*-r " "[\fB@\fP\fIlo\fP][\fB/@\fP\fIhi\fP]" Limit the applicability of output files -- 2.41.0

1 0

Re: [tz] Timezone for Brazil
by Guy Harris Oct. 20, 2023

Oct. 20, 2023

On Oct 8, 2023, at 9:56 AM, Fabrício Rennó via tz <tz(a)iana.org> wrote: > Brazil has officially 4 time zones. > Source: http://www.horalegalbrasil.mct.on.br/HoraLegalBrasileira.php > Expected listed results: > - America/Brazil/Noronha(GMT-02:00) > - America/Brazil/Brasilia(GMT-03:00) > - America/Brazil/Amazonas(GMT-04:00) > - America/Brazil/Acre(GMT-05:00) As https://data.iana.org/time-zones/tz-link.html states: Timezones are typically identified by continent or ocean and then by the name of the largest city within the region containing the clocks. Thus, the IANA database timezones in Brazil, just like time zones in the United States and Canada and Mexico and Germany and India and Nigeria and... do not include the name of the country, and almost always contain the name of a city, not the name of a larger region. Furthermore, IANA database timezones don't just correspond to regions that all currently share an offset from UTC/GMT; they handle not only the current official offset from UTC/GMT, they also handle rules from switching between standard time and daylight saving/summer/etc. time, and even handle changes to the *official standard time offset from UTC/GMT* (which sometimes *does* happen). In addition, there may be IANA database timezones that do not correspond to *current* timezones, but that differed from other regions, either in their standard offset from UTC?GMT or in their time-shifting rules, at some point between 1970 and now. Therefore, the IANA database timezones for Brazil are, with identifications taken from comments in the database source (I'm guessing the two-capital-letter codes are codes for states: America/Noronha - Fernando de Noronha (the comments say "administratively part of PE") America/Belem - Amapá (AP), east Pará (PA) America/Santarem - west Pará America/Fortaleza - Maranhão (MA), Piauí (PI), Ceará (CE), Rio Grande do Norte (RN), Paraíba (PB) America/Recife - Pernambuco (PE) (except Atlantic islands) America/Araguaina - Tocantins (TO) America/Maceio - Alagoas (AL), Sergipe (SE) America/Bahia - Bahia (BA) (the comments say "There are too many Salvadors elsewhere, so use America/Bahia instead of America/Salvador.") America/Sao_Paulo - Goiás (GO), Distrito Federal (DF), Minas Gerais (MG), Espírito Santo (ES), Rio de Janeiro (RJ), São Paulo (SP), Paraná (PR), Santa Catarina (SC), Rio Grande do Sul (RS) America/Campo_Grande - Mato Grosso do Sul (MS) America/Cuiaba - Mato Grosso (MT) America/Porto_Velho - Rondônia (RO) America/Boa_Vista - Roraima (RR) America/Manaus - east Amazonas (AM): Boca do Acre, Jutaí, Manaus, Floriano Peixoto (the comments say "The great circle line from Tabatinga to Porto Acre divides east from west Amazonas.") America/Eirunepe - west Amazonas (AM): Atalaia do Norte, Boca do Maoco, Benjamin Constant, Eirunepé, Envira, Ipixuna America/Rio_Branco - Acre (AC) So: 1) more than you list; 2) no "/Brazil" in the names. Results, on my machine, for 2018-08-04 20:42:19 UTC (chosen because its "seconds since the Epoch" value happened to appear in the "date" manual page on my machine): America/Noronha: UTC-02:00 America/Belem, America/Santarem, America/Fortaleza, America/Recife, America/Araguaina, America/Maceio, America/Bahia, America/Sao_Paulo: UTC-03:00 America/Campo_Grande, America/Cuiaba, America/Porto_Velho, America/Boa_Vista, America/Manaus: UTC-04:00 America/Eirunepe, America/Rio_Branco: UTC-05:00 So: America/Noronha is the only IANA database timezone in the Noronha official Brazilian time zone; America/Belem, America/Santarem, America/Fortaleza, America/Recife, America/Araguaina, America/Maceio, America/Bahia, and America/Sao_Paulo are the IANA database timezones in the Brasilia official Brazilian time zone; America/Campo_Grande, America/Cuiaba, America/Porto_Velho, America/Boa_Vista, and America/Manaus are the IANA database timezones in the Amazonas official Brazilian time zone; America/Eirunepe and America/Rio_Branco are the IANA database timezones in the Acre official Brazilian time zone.

7 21

Fwd: [IANA #1283803] Europe/Amsterdam
by Leo Bekhuis Oct. 18, 2023

Oct. 18, 2023

Please also see the forwarded message. ........................................................................................ We have some kind of a short discussion on a timezone. We are looking for the correct answer. *Is Europe/Amsterdam currently an IANA compliant timezone?* We see in the most recent version it is linked backwards to Europe/Brussels But does that means that Europe/Amsterdam is no longer compliant. Is zone.tab an actual representation of all current iana compliant timezones? We read a first comment line "tzdb timezone descriptions (deprecated version)" ---------- Forwarded message --------- From: David Dong via RT <iana-questions(a)iana.org> Date: Mon, Oct 16, 2023 at 6:18 PM Subject: [IANA #1283803] Europe/Amsterdam To: <leo.bekhuis(a)sqills.com> Hi Leo, Thank you for contacting us. We host the Time Zone Database, but updates are made by the Time Zone Coordinator in consultation with the Time Zone mailing list, in accordance with RFC 6557. You may wish to contact the mailing list, tz(a)iana.org, directly to inquire about Europe/Amsterdam. For mailing list information, please see: http://www.iana.org/time-zones Best regards, David Dong IANA Services Sr. Specialist On Fri Oct 13 09:26:53 2023, leo.bekhuis(a)sqills.com wrote: > Hi, > > We have some kind of a short discussion on a timezone. > > We are looking for the correct answer. > > *Is Europe/Amsterdam currently an IANA compliant timezone?* > > We see in the most recent version it is linked backwards to Europe/Brussels > But does that means that Europe/Amsterdam is no longer compliant. > > Is zone.tab an actual representation of all current iana compliant > timezones? > We read a first comment line "tzdb timezone descriptions (deprecated > version)" > > > Thanks > > > > Leo Bekhuis > > > P +31 887 745 570 > [image: Sqills - exceeding expectations] <https://www.sqills.com> > LinkedIn <https://www.linkedin.com/company/sqills> | Facebook > <https://www.facebook.com/Sqills/> | Twitter <https://twitter.com/sqills> > Sqills has been awarded the ISO 9001:2015, 27001:2017, ISAE 3402, and PCI > DSS certification. We take pride in building secure and high quality > software > This e-mail message is intended exclusively for the addressee or addressees > and may contain personal and/or confidential information. If you have > received this message in error, please notify the sender and delete this > message from your system immediately. > We also request that you neither use the contents nor disclose them in any > manner to third parties, because the message may contain information which > is protected by professional secrecy. > -- Leo Bekhuis P +31 887 745 570 [image: Sqills - exceeding expectations] <https://www.sqills.com> LinkedIn <https://www.linkedin.com/company/sqills> | Facebook <https://www.facebook.com/Sqills/> | Twitter <https://twitter.com/sqills> Sqills has been awarded the ISO 9001:2015, 27001:2017, ISAE 3402, and PCI DSS certification. We take pride in building secure and high quality software This e-mail message is intended exclusively for the addressee or addressees and may contain personal and/or confidential information. If you have received this message in error, please notify the sender and delete this message from your system immediately. We also request that you neither use the contents nor disclose them in any manner to third parties, because the message may contain information which is protected by professional secrecy. -- This e-mail message is intended exclusively for the addressee or addressees and may contain personal and/or confidential information. If you have received this message in error, please notify the sender and delete this message from your system immediately. We also request that you neither use the contents nor disclose them in any manner to third parties, because the message may contain information which is protected by professional secrecy.

3 2

[PROPOSED] Fix Palestine predictions for 2072 through 2075
by Paul Eggert Oct. 16, 2023

Oct. 16, 2023

* asia (Palestine): Move restoration of fall-back transition from 2075 back to 2072. This adds normal fall-back and spring-forward transitions for 2072-10-29, 2073-03-25, 2073-10-28, 2074-03-24, 2074-10-27, 2075-03-30 that were mistakenly omitted in release 2023a. --- NEWS | 8 ++++++++ asia | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 115aff7b..9a085948 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,14 @@ News for the tz database Unreleased, experimental changes + Briefly: + Code and data fixes for Palestine timestamps starting in 2072. + + Changes to future timestamps + + Fix predictions for DST transitions in Palestine in 2072-2075, + correcting a typo introduced in 2023a. + Changes to past and future tm_isdst flags Much of Greenland, represented by America/Nuuk, changed its diff --git a/asia b/asia index 8df2f258..36d7b445 100644 --- a/asia +++ b/asia @@ -3551,13 +3551,13 @@ Rule Palestine 2070 only - Oct 4 2:00 0 - Rule Palestine 2071 only - Sep 19 2:00 0 - Rule Palestine 2072 only - Sep 10 2:00 0 - Rule Palestine 2072 only - Oct 15 2:00 1:00 S +Rule Palestine 2072 max - Oct Sat<=30 2:00 0 - Rule Palestine 2073 only - Sep 2 2:00 0 - Rule Palestine 2073 only - Oct 7 2:00 1:00 S Rule Palestine 2074 only - Aug 18 2:00 0 - Rule Palestine 2074 only - Sep 29 2:00 1:00 S Rule Palestine 2075 only - Aug 10 2:00 0 - Rule Palestine 2075 only - Sep 14 2:00 1:00 S -Rule Palestine 2075 max - Oct Sat<=30 2:00 0 - Rule Palestine 2076 only - Jul 25 2:00 0 - Rule Palestine 2076 only - Sep 5 2:00 1:00 S Rule Palestine 2077 only - Jul 17 2:00 0 - -- 2.41.0

1 0

[PROPOSED] Omit Scattered Islands from zone1970.tab comment
by Paul Eggert Oct. 16, 2023

Oct. 16, 2023

* zone1970.tab: Omit mention of Scattered Islands since we have no reliable info for them. --- zone1970.tab | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zone1970.tab b/zone1970.tab index 1f1cecb8..c510fa58 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -37,7 +37,7 @@ #country- #codes coordinates TZ comments AD +4230+00131 Europe/Andorra -AE,OM,RE,SC,TF +2518+05518 Asia/Dubai Crozet, Scattered Is +AE,OM,RE,SC,TF +2518+05518 Asia/Dubai Crozet AF +3431+06912 Asia/Kabul AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan -- 2.41.0

1 0

[PROPOSED 1/4] Fix zdump diagnostic for missing timezone
by Paul Eggert Oct. 15, 2023

Oct. 15, 2023

* zdump.c (main): Fix typo in diagnostic for ‘zdump -i nosuchzone’. --- zdump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/zdump.c b/zdump.c index 6f9573ec..7d99cc74 100644 --- a/zdump.c +++ b/zdump.c @@ -602,7 +602,7 @@ main(int argc, char *argv[]) if (!tz) { char const *e = strerror(errno); fprintf(stderr, _("%s: unknown timezone '%s': %s\n"), - progname, argv[1], e); + progname, argv[i], e); return EXIT_FAILURE; } if (now) { -- 2.41.0

1 3

Re: [tz] Winter Time in Palestine for 2023s year
by Paul Eggert Oct. 10, 2023

Oct. 10, 2023

On 10/9/23 10:06, Derick Rethans wrote: > The attached PDF had different spring dates for 2024-2026 compared to > what tzdata has predicted. Yes, but that PDF is simply page 2 of the PDF dated 2022-08-22 that we received in August 2022[1]. This was later superseded by the March 2023 cabinet decision[2]. I guess that the email we received today[3] copies the August 2022 communique merely to support the statement that Palestine's fall transition is the same that what was planned in August 2022. TZDB currently predicts that Palestine's spring transition will be April 13, 2024 at 02:00, contrary to [1] and [3] (which have the transition on March 30) but more consistent with [2] (which says Palestine used standard time during Ramadan 2023). It would be helpful if the Palestinian cabinet could confirm TZDB's guess soon, rather than wait until April next year, because if TZDB's guess is wrong it will take some time to propagate fixes out to cell phones and computers. [1]: https://mm.icann.org/pipermail/tz/2022-August/031887.html [2]: https://mm.icann.org/pipermail/tz/2023-March/032733.html [3]: https://mm.icann.org/pipermail/tz/2023-October/033075.htm

2 1

Asia/Tbilisi
by Maria Mkrtichiani Oct. 9, 2023

Oct. 9, 2023

Good afternoon, Hope you are doing well. We find out that our e-commerce platform uses the information about regions from IANA. There is Asia/Tbilisi, it should be Georgia/Tbilisi. Can you please change it? Thank you in advance, Maria Classification: Official [cid:image001.jpg@01D9FAAF.CC4D9E80] MARIA MKRTICHIANI PROJECT MANAGER UGT LTD 17a Chavchavadze Avenue, 0179, Tbilisi, Georgia T. +995 32 222 05 05 M. +995 579 991 951 | Maria.mkrtichiani(a)ugt.ge<mailto:Maria.mkrtichiani@ugt.ge> | www.ugt.ge<http://www.ugt.ge/> ________________________________ This email and attachments may contain confidential information and/or copyright material. This email is intended for the use of the addressee only. Any unauthorised use may be unlawful. If you receive this email by mistake, please advise the sender immediately by using the reply facility in your email software, immediately delete the original e-mail and it's attachments from your system and do not disclose or otherwise take any action against its content. While this email has been scanned for all known viruses, internet communications may not be secure or virus-free; UGT does not accept responsibility for any damage arising from unauthorized access to this e-mail, or interference with, by any third-party.

3 2