- tz - lists.iana.org

[PROPOSED 1/7] Avoid undefined behavior if no Link lines
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Don't call qsort(NULL, 0, ...) as this has undefined behavior in C. This fixes a bug introduced five days ago. --- zic.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/zic.c b/zic.c index 78afa67..a699285 100644 --- a/zic.c +++ b/zic.c @@ -683,7 +683,8 @@ static void make_links(void) { ptrdiff_t i, j, nalinks; - qsort(links, nlinks, sizeof *links, qsort_linkcmp); + if (nlinks) + qsort(links, nlinks, sizeof *links, qsort_linkcmp); /* Ignore each link superseded by a later link with the same name. */ j = 0; -- 2.37.3

9 33

[PROPOSED] Fix recently-introduced zic infloop
by Paul Eggert Oct. 28, 2022

Oct. 28, 2022

* zic.c (make_links): Diagnose link cycles instead of looping. --- zic.c | 20 +++++++++++++++++--- 1 file changed, 17 insertions(+), 3 deletions(-) diff --git a/zic.c b/zic.c index 4222869..501718f 100644 --- a/zic.c +++ b/zic.c @@ -688,7 +688,7 @@ bsearch_linkcmp(void const *key, void const *b) static void make_links(void) { - ptrdiff_t i, j, nalinks; + ptrdiff_t i, j, nalinks, pass_size; if (1 < nlinks) qsort(links, nlinks, sizeof *links, qsort_linkcmp); @@ -700,7 +700,7 @@ make_links(void) i++; links[j++] = links[i]; } - nlinks = j; + nlinks = pass_size = j; /* Walk through the link array making links. However, if a link's target has not been made yet, append a copy to the @@ -739,8 +739,22 @@ make_links(void) eat(links[i].l_filenum, links[i].l_linenum); /* If this pass examined all its links, start the next pass. */ - if (i == j) + if (i == j) { + if (nalinks - i == pass_size) { + error(_("\"Link %s %s\" is part of a link cycle"), + links[i].l_target, links[i].l_linkname); + break; + } j = nalinks; + pass_size = nalinks - i; + } + + /* Diagnose self links, which the cycle detection algorithm would not + otherwise catch. */ + if (strcmp(links[i].l_target, links[i].l_linkname) == 0) { + error(_("link %s targets itself"), links[i].l_target); + continue; + } /* Make this link unless its target has not been made yet. */ l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), -- 2.37.3

1 0

[PROPOSED 1/2] Don’t include <sys/type.h>
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

* private.h: Do not include <sys/types.h> for time_t. Including sys/types.h was added on 1989-04-10 to support pre-C89 platforms, but this is no longer needed now that we assume C89. --- private.h | 1 - 1 file changed, 1 deletion(-) diff --git a/private.h b/private.h index ffb9d48..baacdfb 100644 --- a/private.h +++ b/private.h @@ -179,7 +179,6 @@ #undef tzfree #include <stddef.h> -#include <sys/types.h> /* for time_t */ #include <string.h> #include <limits.h> /* for CHAR_BIT et al. */ #include <stdlib.h> -- 2.37.3

1 1

[PROPOSED] Fix zdump undefined behavior if !USE_LTZ
by Paul Eggert Oct. 27, 2022

Oct. 27, 2022

When compiled with -DUSE_LTZ=0, zdump modified pointers in the environ vector, which POSIX says results in undefined behavior. Fix this by using setenv if available, otherwise by arranging for the modifications to occur to the vector before it's assigned or re-assigned to ‘environ’. * Makefile, NEWS: Mention this. * private.h (HAVE_SETENV): Default to 1. * zdump.c (tzalloc): If HAVE_SETENV, just use setenv; it’s simpler. Otherwise, avoid modifying environ, environ[0], environ[0][0], etc. while environ is in use by getenv etc. Do this by keeping two independent environ vectors; the original one and fakeenv. If !HAVE_SETENV, return the initial environ array. (tzalloc, tzfree): Give the getenv family a chance of getting the correct answer, by calling tzset after each time the environment is modified. (tzfree): Restore the initial environ array. --- Makefile | 1 + NEWS | 4 ++++ private.h | 4 ++++ zdump.c | 57 ++++++++++++++++++++++++++++++++++++++----------------- 4 files changed, 49 insertions(+), 17 deletions(-) diff --git a/Makefile b/Makefile index d3cfbd0..34cec49 100644 --- a/Makefile +++ b/Makefile @@ -223,6 +223,7 @@ LDLIBS= # -DHAVE_MALLOC_ERRNO=0 if malloc etc. do not set errno on failure. # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX +# -DHAVE_SETENV=0 if your system lacks the setenv function # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h>* # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l diff --git a/NEWS b/NEWS index a918aed..546fe11 100644 --- a/NEWS +++ b/NEWS @@ -73,6 +73,10 @@ Unreleased, experimental changes releases have been out of support since 2019. This change affects only fat TZif files, as thin files never had the workaround. + zdump no longer modifies the environ vector when compiled on + platforms lacking tm_zone or when compiled with -DUSE_LTZ=0. + This avoid undefined behavior on POSIX platforms. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 2c7535d..ffb9d48 100644 --- a/private.h +++ b/private.h @@ -87,6 +87,10 @@ # define HAVE_POSIX_DECLS 1 #endif +#ifndef HAVE_SETENV +# define HAVE_SETENV 1 +#endif + #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif diff --git a/zdump.c b/zdump.c index 168f72a..ffb321a 100644 --- a/zdump.c +++ b/zdump.c @@ -228,33 +228,56 @@ mktime_z(timezone_t tz, struct tm *tmp) static timezone_t tzalloc(char const *val) { +# if HAVE_SETENV + if (setenv("TZ", val, 1) != 0) { + perror("setenv"); + exit(EXIT_FAILURE); + } + tzset(); + return NULL; +# else + enum { TZeqlen = 3 }; + static char const TZeq[TZeqlen] = "TZ="; static char **fakeenv; - char **env = fakeenv; - char *env0; - if (! env) { - char **e = environ; - int to; + static size_t fakeenv0size; + void *freeable = NULL; + char **env = fakeenv, **initial_environ; + size_t valsize = strlen(val) + 1; + if (fakeenv0size < valsize) { + char **e = environ, **to; + ptrdiff_t initial_nenvptrs; /* Counting the trailing NULL pointer. */ while (*e++) continue; - env = xmalloc(sumsize(sizeof *environ, - (e - environ) * sizeof *environ)); - to = 1; - for (e = environ; (env[to] = *e); e++) - to += strncmp(*e, "TZ=", 3) != 0; + initial_nenvptrs = e - environ; + fakeenv0size = sumsize(valsize, valsize); + fakeenv0size = max(fakeenv0size, 64); + freeable = env; + fakeenv = env = + xmalloc(sumsize(sumsize(sizeof *environ, + initial_nenvptrs * sizeof *environ), + sumsize(TZeqlen, fakeenv0size))); + to = env + 1; + for (e = environ; (*to = *e); e++) + to += strncmp(*e, TZeq, TZeqlen) != 0; + env[0] = memcpy(to + 1, TZeq, TZeqlen); } - env0 = xmalloc(sumsize(sizeof "TZ=", strlen(val))); - env[0] = strcat(strcpy(env0, "TZ="), val); - environ = fakeenv = env; + memcpy(env[0] + TZeqlen, val, valsize); + initial_environ = environ; + environ = env; tzset(); - return env; + free(freeable); + return initial_environ; +# endif } static void -tzfree(timezone_t env) +tzfree(timezone_t initial_environ) { - environ = env + 1; - free(env[0]); +# if !HAVE_SETENV + environ = initial_environ; + tzset(); +# endif } #endif /* ! USE_LOCALTIME_RZ */ -- 2.37.3

1 0

[PROPOSED 1/2] Default time_t to 64 bits on glibc 2.34+ 32-bit
by Paul Eggert Oct. 26, 2022

Oct. 26, 2022

* NEWS: Mention this. * private.h (_TIME_BITS): Default to 64. --- NEWS | 8 ++++++++ private.h | 12 ++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index bddbd3da..a918aed2 100644 --- a/NEWS +++ b/NEWS @@ -57,6 +57,14 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + On glibc 2.34 and later, which optionally supports 64-bit time_t + on platforms like x86 where time_t was traditionally 32 bits, + default time_t to 64 instead of 32 bits. This lets functions like + localtime support timestamps after the year 2038, and fixes + year-2038 problems in zic when accessing files dated after 2038. + To continue to limit time_t to 32 bits on these platforms, use + "make CFLAGS='-D_TIME_BITS=32'". + In C code, prefer C23 keywords to pre-C23 macros for alignof, bool, false, and true. Also, use the following C23 features if available: __has_include, unreachable. diff --git a/private.h b/private.h index c185d5f3..2c7535d8 100644 --- a/private.h +++ b/private.h @@ -127,8 +127,9 @@ /* Enable strtoimax on pre-C99 Solaris 11. */ #define __EXTENSIONS__ 1 -/* To avoid having 'stat' fail unnecessarily with errno == EOVERFLOW, - enable large files on GNUish systems ... */ +/* Although tzcode does not call 'stat'-like functions directly, stdio + functions may call them. To avoid having them fail unnecessarily + with errno == EOVERFLOW, enable large files on GNUish systems ... */ #ifndef _FILE_OFFSET_BITS # define _FILE_OFFSET_BITS 64 #endif @@ -137,6 +138,13 @@ /* ... and enable large inode numbers on Mac OS X 10.5 and later. */ #define _DARWIN_USE_64_BIT_INODE 1 +/* On GNUish systems where time_t might be 32 or 64 bits, use 64. + This supports a wider time range, and avoids having 'stat'-like + functions fail unnecessarily with errno == EOVERFLOW. */ +#ifndef _TIME_BITS +# define _TIME_BITS 64 +#endif + /* ** Nested includes */ -- 2.37.2

1 1

Re: [tz] tz Digest, Vol 133, Issue 32
by richa＠msn.com Oct. 24, 2022

Oct. 24, 2022

Once again, "All problems in computer science can be solved by another level of indirection." ________________________________ From: tz <tz-bounces(a)iana.org> on behalf of tz-request(a)iana.org <tz-request(a)iana.org> Sent: Monday, October 24, 2022 7:00 AM To: tz(a)iana.org <tz(a)iana.org> Subject: tz Digest, Vol 133, Issue 32 Send tz mailing list submissions to tz(a)iana.org To subscribe or unsubscribe via the World Wide Web, visit https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.… or, via email, send a message with subject or body 'help' to tz-request(a)iana.org You can reach the person managing the list at tz-owner(a)iana.org When replying, please edit your Subject line so it is more specific than "Re: Contents of tz digest..."

1 0

[PROPOSED 1/2] zic now supports links to links
by Paul Eggert Oct. 24, 2022

Oct. 24, 2022

* NEWS, backward, zic.8: Mention this. * zic.c (make_links): New function, which supports links to later links. In this function, improve quality of warnings about links to links. (main): Use it. --- NEWS | 14 ++++++++ backward | 6 ++-- zic.8 | 29 ++++++++++++++--- zic.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++++-------- 4 files changed, 126 insertions(+), 20 deletions(-) diff --git a/NEWS b/NEWS index 64a2d0c..f400d71 100644 --- a/NEWS +++ b/NEWS @@ -5,6 +5,7 @@ Unreleased, experimental changes Briefly: Move links to 'backward'. In vanguard form, GMT is now a Zone and Etc/GMT a link. + zic now supports links to links. Simplify four Ontario zones into one. Fix a Y2438 bug when reading TZif data. @@ -28,6 +29,19 @@ Unreleased, experimental changes Changes to code + zic now supports links to links regardless of input line order. + For example, if Australia/Sydney is a Zone, the lines + Link Australia/Canberra Australia/ACT + Link Australia/Sydney Australia/Canberra + now work correctly, even though the shell commands + ln Australia/Canberra Australia/ACT + ln Australia/Sydney Australia/Canberra + would fail because the first command attempts to use a link + Australia/Canberra that does not exist until after the second + command is executed. Previously, zic had unspecified behavior if + a Link line's target was another link, and zic often misbehaved if + a Link line's target was a later Link line. + Fix line number in zic's diagnostic for a link to a link. Fix a bug that caused localtime to mishandle timestamps starting diff --git a/backward b/backward index 101cbc0..4c1c5d5 100644 --- a/backward +++ b/backward @@ -17,9 +17,9 @@ # backward compatibility link. Each section is sorted by link name. # A "#= TARGET1" comment labels each link inserted only because some -# .zi parsers mishandle links to links. The comment says what the -# target would be if these parsers were fixed so that data could -# contain links to links. For example, the line +# .zi parsers (including tzcode through 2022e) mishandle links to links. +# The comment says what the target would be if these parsers were fixed +# so that data could contain links to links. For example, the line # "Link Australia/Sydney Australia/ACT #= Australia/Canberra" would be # "Link Australia/Canberra Australia/ACT" were it not that data lines # refrain from linking to links like Australia/Canberra, which means diff --git a/zic.8 b/zic.8 index e46d0ab..f79148f 100644 --- a/zic.8 +++ b/zic.8 @@ -190,7 +190,10 @@ the named file rather than in the standard location. Be more verbose, and complain about the following situations: .RS .PP -The input specifies a link to a link. +The input specifies a link to a link, +something not supported by some older parsers, including +.B zic +itself through release 2022e. .PP A year that appears in a data file is outside the range of representable years. @@ -691,19 +694,37 @@ The .B TARGET field should appear as the .B NAME -field in some zone line. +field in some zone line or as the +.B LINK-NAME +field in some link line. The .B LINK-NAME field is used as an alternative name for that zone; it has the same syntax as a zone line's .B NAME field. +Links can chain together, although the behavior is unspecified if a +chain of one or more links does not terminate in a Zone name. +A link line can appear before the line that defines the link target. +For example: +.sp +.ne 3 +.nf +.in +2m +.ta \w'Zone\0\0'u +\w'Greenwich\0\0'u +Link Greenwich G_M_T +Link Etc/GMT Greenwich +Zone Etc/GMT\0\00\0\0\*-\0\0GMT +.sp +.in +.fi +The two links are chained together, and G_M_T, Greenwich, and Etc/GMT +all name the same zone. .PP Except for continuation lines, lines may appear in any order in the input. However, the behavior is unspecified if multiple zone or link lines -define the same name, or if the source of one link line is the target -of another. +define the same name. .PP The file that describes leap seconds can have leap lines and an expiration line. diff --git a/zic.c b/zic.c index 82e1a4d..78afa67 100644 --- a/zic.c +++ b/zic.c @@ -678,6 +678,89 @@ bsearch_linkcmp(void const *key, void const *b) return strcmp(key, m->l_linkname); } +/* Make the links specified by the Link lines. */ +static void +make_links(void) +{ + ptrdiff_t i, j, nalinks; + qsort(links, nlinks, sizeof *links, qsort_linkcmp); + + /* Ignore each link superseded by a later link with the same name. */ + j = 0; + for (i = 0; i < nlinks; i++) { + while (i + 1 < nlinks + && strcmp(links[i].l_linkname, links[i + 1].l_linkname) == 0) + i++; + links[j++] = links[i]; + } + nlinks = j; + + /* Walk through the link array making links. However, + if a link's target has not been made yet, append a copy to the + end of the array. The end of the array will gradually fill + up with a small sorted subsequence of not-yet-made links. + nalinks counts all the links in the array, including copies. + When we reach the copied subsequence, it may still contain + a link to a not-yet-made link, so the process repeats. + At any given point in time, the link array consists of the + following subregions, where 0 <= i <= j <= nalinks and + 0 <= nlinks <= nalinks: + + 0 .. (i - 1): + links that either have been made, or have been copied to a + later point point in the array (this later point can be in + any of the three subregions) + i .. (j - 1): + not-yet-made links for this pass + j .. (nalinks - 1): + not-yet-made links that this pass has skipped because + they were links to not-yet-made links + + The first subregion might not be sorted if nlinks < i; + the other two subregions are sorted. This algorithm does + not alter entries 0 .. (nlinks - 1), which remain sorted. + + If there are L links, this algorithm is O(C*L*log(L)) where + C is the length of the longest link chain. Usually C is + short (e.g., 3) though its worst-case value is L. */ + + j = nalinks = nlinks; + + for (i = 0; i < nalinks; i++) { + struct link *l; + + eat(links[i].l_filenum, links[i].l_linenum); + + /* If this pass examined all its links, start the next pass. */ + if (i == j) + j = nalinks; + + /* Make this link unless its target has not been made yet. */ + l = bsearch(links[i].l_target, &links[i + 1], j - (i + 1), + sizeof *links, bsearch_linkcmp); + if (!l) + l = bsearch(links[i].l_target, &links[j], nalinks - j, + sizeof *links, bsearch_linkcmp); + if (!l) + dolink(links[i].l_target, links[i].l_linkname, false); + else { + /* The link target has not been made yet; copy the link to the end. */ + links = growalloc (links, sizeof *links, nalinks, &nlinks_alloc); + links[nalinks++] = links[i]; + } + + if (noise && i < nlinks) { + if (l) + warning(_("link %s targeting link %s mishandled by pre-2023 zic"), + links[i].l_linkname, links[i].l_target); + else if (bsearch(links[i].l_target, links, nlinks, sizeof *links, + bsearch_linkcmp)) + warning(_("link %s targeting link %s"), + links[i].l_linkname, links[i].l_target); + } + } +} + /* Simple signal handling: just set a flag that is checked periodically outside critical sections. To set up the handler, prefer sigaction if available to close a signal race. */ @@ -992,19 +1075,7 @@ _("%s: invalid time range: %s\n"), continue; outzone(&zones[i], j - i); } - /* - ** Make links. - */ - if (noise) - qsort(links, nlinks, sizeof *links, qsort_linkcmp); - for (i = 0; i < nlinks; ++i) { - eat(links[i].l_filenum, links[i].l_linenum); - dolink(links[i].l_target, links[i].l_linkname, false); - if (noise - && bsearch(links[i].l_target, links, nlinks, sizeof *links, - bsearch_linkcmp)) - warning(_("link to link")); - } + make_links(); if (lcltime != NULL) { eat(COMMAND_LINE_FILENUM, 1); dolink(lcltime, tzdefault, true); -- 2.37.3

1 1

Pacific islands as identifiers
by Paul-Cathy Unger Oct. 22, 2022

Oct. 22, 2022

Hi, I was recently setting the time zone on my computer to my current location -- Honiara, Solomon Islands. In my operating system's drop-down list of "Cities" (I use a Linux distro based on Ubuntu), I could not find Honiara. I finally ended up clicking on the map approximately where I thought it would be. To my surprise, where I clicked had the label "Guadalcanal". I wasn't expecting that, and certainly wasn't looking for Guadalcanal in the list -- Honiara would have made a lot more sense to me (e.g., https://www.timeanddate.com/time/zone/solomon-islands) I'm wondering what the rationale is for using island / province names for some Pacific nations and city names for others (e.g., Apia, Samoa; Port Moresby, PNG)? And I wonder if knowing that there are historic animosities in a country between people from one island and another would be enough to consider changing an apparent favouring of one island over another? For a brief and somewhat current analysis, see https://www.csis.org/analysis/deep-roots-solomon-islands-ongoing-political-…. I offer this for your kind consideration, Paul Unger

2 1

[PROPOSED 1/7] Port better to C23 bool
by Paul Eggert Oct. 20, 2022

Oct. 20, 2022

* private.h (HAVE_STDBOOL_H): Remove. (true, false, bool): Simply rely on __STDC_VERSION__. There’s no longer need to treat pre-C99 compilers with <stdbool.h> specially, as they can be treated as if they lack <stdbool.h>. --- Makefile | 1 - NEWS | 3 +++ private.h | 10 +++------- 3 files changed, 6 insertions(+), 8 deletions(-) diff --git a/Makefile b/Makefile index 156840e..afe7af7 100644 --- a/Makefile +++ b/Makefile @@ -223,7 +223,6 @@ LDLIBS= # -DHAVE_POSIX_DECLS=0 if your system's include files do not declare # functions like 'link' or variables like 'tzname' required by POSIX # -DHAVE_SNPRINTF=0 if your system lacks the snprintf function -# -DHAVE_STDBOOL_H if you have a non-C99 compiler with <stdbool.h> # -DHAVE_STDINT_H if you have a non-C99 compiler with <stdint.h> # -DHAVE_STRFTIME_L if <time.h> declares locale_t and strftime_l # -DHAVE_STRDUP=0 if your system lacks the strdup function diff --git a/NEWS b/NEWS index 164ab95..16f454c 100644 --- a/NEWS +++ b/NEWS @@ -37,6 +37,9 @@ Unreleased, experimental changes number 2438 comes from the 32-bit limit in the year 2038, plus the 400-year Gregorian cycle. (Problem reported by Bradley White.) + Take advantage of the following C23 features if available: + bool/true/false keywords. + Release 2022e - 2022-10-11 11:13:02 -0700 diff --git a/private.h b/private.h index 9c31ec5..058d3c0 100644 --- a/private.h +++ b/private.h @@ -74,10 +74,6 @@ # define HAVE_POSIX_DECLS 1 #endif -#ifndef HAVE_STDBOOL_H -# define HAVE_STDBOOL_H (199901 <= __STDC_VERSION__) -#endif - #ifndef HAVE_STRDUP # define HAVE_STRDUP 1 #endif @@ -623,12 +619,12 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; ** Finally, some convenience items. */ -#if HAVE_STDBOOL_H -# include <stdbool.h> -#else +#if __STDC_VERSION__ < 199901 # define true 1 # define false 0 # define bool int +#elif __STDC_VERSION__ < 202311 +# include <stdbool.h> #endif #define TYPE_BIT(type) (sizeof(type) * CHAR_BIT) -- 2.37.3

1 6

[PATCH 0/5] Simplifying Link line maintenance
by Paul Eggert Oct. 17, 2022

Oct. 17, 2022

Although TZDB currently puts most Link lines in the ‘backward’ file, some Link lines reside in the continental files ‘africa’, ‘antarctica’, etc., with little rhyme or reason as to which lines are in ‘backward’ and which line are in a continental file. This is confusing and makes maintenance a bit more difficult. This proposed series of patches aims to regularize this by putting the Link lines into ‘backward’, except that to work around a TZUpdater bug the GMT Link line is in ‘backward’ only when using vanguard form. As part of these patches, the Link lines in ‘backward’ are organized into sections that better explain the reason for each Link line. Also, comments are added to document shortcut Link lines, that is, Link lines reworded to reference the target rather than the source of another Link line. Furthermore, the Makefile is augmented to check Link lines more carefully. The overall effect of this patch is to shrink TZDB’s source code and make maintenance simpler and more robust, without affecting data except for users who are purposely bleeding-edge by omitting all backward-compatibility links. Because these patches are nontrivial I have not installed them in the development repository, and there is no rush. Comments welcome as usual. Paul Eggert (5): Move a few links to ‘backward’ Move most remaining links to ‘backward’ Reorder 'backward’ Improve checking for shortcut links Coalesce some commentary Makefile | 6 +- NEWS | 17 +++ africa | 213 ++++++++++-------------------------- antarctica | 2 +- asia | 69 ++++-------- australasia | 46 +++----- backward | 288 +++++++++++++++++++++++++++++++++++++++---------- checklinks.awk | 17 +++ etcetera | 17 ++- europe | 202 ++++++++++++---------------------- northamerica | 86 ++++----------- southamerica | 15 --- theory.html | 1 + zdump.c | 4 +- ziguard.awk | 14 +++ 15 files changed, 472 insertions(+), 525 deletions(-) -- 2.37.3

2 8

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 17, 2022

Oct. 17, 2022

Individual reserves usually have their own names such as the one near Fort Frances, "Nigigoonsiminikaaning" (Little Otters Playing). If the whole treaty area followed a rule than I agree that the treaty name would be a good solution. ----- Original Message ----- From: Brian Inglis via tz [mailto:tz@iana.org] To: <tz(a)iana.org> Sent: Sat, 15 Oct 2022 17:35:27 -0600 Subject: Re: [tz] Northern Ontario (Canada) Hi folks, Given that ids are named for the largest municipality observing given rules, and those named municipalities are not documented as nor likely to have diverged from provincial rules, then applying those ids to rural areas, especially reserves, would be erroneous. In the case of Canadian rural reserves, large areas are normally covered by the federal treaties under which those settlements were negotiated, and if reserves in those treaty areas could be documented to have ignored DST, then perhaps better ids would be e.g. Treaty3 for the ON Lake of the Woods Area, and Treaty60 for the ON Nipigon Lake area, given that other applicable labels are likely to be either confusing, excessively long, or require uncommon fonts to render? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry On 2022-10-15 17:02, Chris Walton via tz wrote: > Paul, > The changes look correct except that you linked *America/Rainy_River* to > *America/Toronto* instead of *America/Winnipeg*. > Rainy River is west of 90°W and needs to remain on Central Time. > > David, > I don't deny that there may have been some small reserves that did not observe > daylight saving. > They could still be added to the database if somebody wants to do the research > and provide appropriate names. > However, it would be wrong to use the names of existing towns and cities to > represent small reserves that exist outside of those towns and cities. > > -chris > > On Sat, 15 Oct 2022 at 17:11, dpatte <dpatte(a)relativedata.com > <mailto:dpatte@relativedata.com>> wrote: > > My concern about these changes is that I seem to remember that some first > nations in those areas did not use daylight-savings time on their reserves, > and that they were real but very small 'zones', not the large zones they > ended up being assumed to be. > > Unfortunately I have no documentation either way on this. > > > *----- Original Message -----* > *From:* Paul Eggert via tz [mailto:tz@iana.org] <mailto:tz@iana.org> > *To:* "Chris Walton" <crj.walton(a)gmail.com <mailto:crj.walton@gmail.com>> > *Cc:* tz(a)iana.org <mailto:tz@iana.org> > *Sent:* Sat, 15 Oct 2022 12:53:28 -0700 > *Subject:* Re: [tz] Northern Ontario (Canada) > > Thank you for doing that investigative work. Proposed patch attached and > installed into the tzdb development repository on GitHub. > > This patch follows your suggestions, except that it moves Nipigon's and > Rainy River's dubious data to 'backzone' instead of removing them > entirely, as I worry that some users will want the appearance of > completeness no matter how illusory.

2 1

Re: [tz] Northern Ontario (Canada)
by dpatte Oct. 16, 2022

Oct. 16, 2022

My concern about these changes is that I seem to remember that some first nations in those areas did not use daylight-savings time on their reserves, and that they were real but very small 'zones', not the large zones they ended up being assumed to be. Unfortunately I have no documentation either way on this. ----- Original Message ----- From: Paul Eggert via tz [mailto:tz@iana.org] To: "Chris Walton" <crj.walton(a)gmail.com> Cc: tz(a)iana.org Sent: Sat, 15 Oct 2022 12:53:28 -0700 Subject: Re: [tz] Northern Ontario (Canada) Thank you for doing that investigative work. Proposed patch attached and installed into the tzdb development repository on GitHub. This patch follows your suggestions, except that it moves Nipigon's and Rainy River's dubious data to 'backzone' instead of removing them entirely, as I worry that some users will want the appearance of completeness no matter how illusory.

4 3

Northern Ontario (Canada)
by Chris Walton Oct. 15, 2022

Oct. 15, 2022

On January 1, 1970, the twin cities of Fort William and Port Arthur were merged to form the City of Thunder Bay. The TZ database currently shows that Thunder Bay has observed daylight saving every year from 1970 onwards with the exception of 1973. Back in July I raised some doubts on this mailing list about the 1973 data. I now have more proof that it is wrong. Somebody from the Thunder Bay Public Library was kind enough to send me two newspaper scans from 1973. Both scans are from the Chronicle Journal which has been a local Thunder Bay newspaper since 1972. *Chronicle Journal - Saturday April 28, 1973 - page 1* This page contains a slightly corny but very relevant notice titled "*Clocks Move Ahead Sunday*''. It reads: > Advancing an hour glass one hour for daylight saving time appears to pose > a problem for Pat Plachta. She knows DST begins at 2 a.m. Sunday and she'll > have one less hour to sleep in the morning but she'll make it up in the > Fall. Above the article is a picture of a woman holding an hourglass. Being that this is a Thunder Bay newspaper, the implication is that Thunder Bay did observe daylight saving in 1973. For completeness, I will also mention that the same newspaper page also contains a generic Canadian Press article titled "*Canadians Will Lose Hour Sleep*". The article briefly documents daylight saving practices across the country with no mention of any specific towns or cities. It starts out with: > OTTAWA (CP) — 12:01 a.m. becomes 1:01 a.m. in Canada Sunday. ... Clearly that first line is not entirely correct because most (but not all) of Canada was doing the switch at 2:00a.m. instead of 12:01a.m. I am not quoting the entire article here because it is not specific to Thunder Bay and there is nothing in it that we do not already know. *Chronicle Journal - Saturday October 27, 1973 - page 1* This page contains a notice titled "*Extra Sleep*". It reads: > Tonight city residents can look forward to gaining an extra hour of rest, > as Thunder Bay goes from Daylight Saving Time to Eastern Standard Time. So > don't forget to set your clocks back an hour tonight at 12:01 a.m. I will assume that 12:01 is an error; since most cities and towns in Ontario switched at 2:00a.m. Regardless, the notice provides additional proof that Thunder Bay did observe daylight saving in 1973. The TZ database entry for *America/Thunder_Bay* should be updated to include the observance of daylight saving in 1973. This change will make *America/Thunder_Bay* identical to *America/Toronto* from October 26, 1969 until present. Ultimately, *America/Thunder_Bay *could be replaced with a link. It could also be maintained in the backzone file using pre-1970 history from either Port Arthur or Fort William. Both Port Arthur and Fort William started their first experiments with daylight saving on May 2, 1908 which is not currently reflected in the *America/Thunder_Bay* data. Unfortunately I do not have a complete history for Port Arthur or Fort William however there are a couple of sources to start with: https://www.thunderbay.ca/en/inc/blog.aspx (scroll to the bottom) http://www.bayviewmagazine.com/article/2022/03/great-springing-forward-deba… Also, I would also like to see *America/Nipigon *and* America/Rainy_River* converted into link entries because I have zero faith in the current Shanks based data. America/Nipigon --> America/Toronto America/Rainy_River --> America/Winnipeg I am not convinced it is worth saving the data for either of these two questionable zones inside the backzone file. As I pointed out in July, the TZ database shows that Nipigon started daylight saving in 1974, but newspaper evidence shows it was already using daylight saving at least as far back as 1972. https://news.ourontario.ca/npl/122271/page/2 And FYI: The *America/Nipigon* and *America/Rainy_River* boundaries were removed from OpenStreetMap back in August. The *America/Toronto* boundary was restored to include most of Ontario east of 90°W. I was happy to see it done. -chris

2 1

time keeps on slipping into the future
by Bradley White Oct. 15, 2022

Oct. 15, 2022

tzfile.5 says: > After the second header and data comes a newline-enclosed, > POSIX-TZ-environment-variable-style string for use in handling > instants after the last transition time stored in the file I had imagined that the reference implementation would apply the future rule for all of the future, but I currently observe that UTC-offset changes get stuck after a while for many (but not all) zones. For example, for *"Australia/Sydney"*, whose POSIX TZ string is *"AEST-10AEDT,M10.1.0,M4.1.0/3"*, tz_localtime_rz() produces the following civil times at the given instants: 14745254399 = 2437-04-05T02:59:59+1100 14745254400 = 2437-04-05T02:00:00+1000 14760979199 = 2437-10-04T01:59:59+1000 14760979200 = 2437-10-04T03:00:00+1100 That looks good ... daylight time from the first Sunday in Oct through the first Sunday in Apr, shifting at 03:00. But once we hit 2438, the UTC offset is stuck at +1100. For example, in July we would expect to see standard time, but instead get: 14784296400 = 2438-07-01T00:00:00+1100 And it never seems to recover after that. I'm pretty sure this used to work.

2 8

Jordan DST - News
by Issam AlZawairi Oct. 11, 2022

Oct. 11, 2022

Hello, The Council of Ministers in Jordan decided Wednesday 5th October 2022, that daylight saving time (DST) will be throughout the year. Here's a link from an official news website https://en.royanews.tv/news/37769/2022-10-05 Thanks for creating a new TZ DB version. P Please consider the environment before printing this email Issam Al-Zuwairi DevOps Manager - Technology and Digital Innovation Zain Jordan [cid:image001.png@01D8D8B7.02E841A0] M: 00962797612342 T: 00962797900900 ext: 5809 E: <mailto:%7bemail%7d> issam.alzawairi(a)jo.zain.com<mailto:issam.alzawairi@jo.zain.com> www.jo.zain.com<http://www.jo.zain.com/> [cid:image002.jpg@01D8D8B7.02E841A0]

3 4

[tz-announce] 2022e release of tz code and data
by Paul Eggert via tz-announce Oct. 11, 2022

Oct. 11, 2022

The 2022e release of the tz code and data is available. This release reflects the following changes: Briefly: Jordan and Syria switch from +02/+03 with DST to year-round +03. Changes to future timestamps Jordan and Syria are abandoning the DST regime and are changing to permanent +03, so they will not fall back from +03 to +02 on 2022-10-28. (Thanks to Steffen Thorsen and Issam Al-Zuwairi.) Changes to past timestamps On 1922-01-01 Tijuana adopted standard time at 00:00, not 01:00. Changes to past time zone abbreviations and DST flags The temporary advancement of clocks in central Mexico in summer 1931 is now treated as daylight saving time, instead of as two changes to standard time. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022e.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022e.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit c4eb3fcf2fc736b7924176cf9c3f9c305c398b8b dated 2022-10-11 11:13:02 -0700 and tagged '2022e' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 7b3771bfa024d0bf445256f4d837a046eaba910ca3f2a5b4fcaf72ddd5fe34a9318a68f94ee09c0de120f3bdea41e9a16b0e82763896df8a6254ced0b454c060 tzcode2022e.tar.gz 3b63ba2662930ee13dec79290f57545d71d21d4ddb76f94498a7096edaee0b3150e501c221c4d596df6af7c1d770c211f88feb5add13c5e3bed979218b4544da tzdata2022e.tar.gz 6b316ac2d9dfe615685164accd126ee29c363fafe0d3483ac155644c5693693758e7315aa9f55c0a3e3c027d38f1125462d84a13fd424458b86f6be33f153cc7 tzdb-2022e.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBIACgkQ7ZfpDmKq fjR5uxAAncvLsl0jRRUoY/5t92LNweU9UG3qTV6k3Y8GMlY6vOl3LFPM/Be9RKzr oJ6z3JNjOHTeE69Y8xWDqzcxyKiFIyJV3l9p0Pc6JiBWWmI/MOarja3PjGsw8v0C jv4pV+Qm5zObEvtIBboOsK5WE26/5zzP0mlW+zseAu9Qj2Ed9MuAB4xw7SDHlzWN k49SwPeeIrnW6z4iIx55KHZv2bn7XSytw1X5ZsVEizEzO+uNJh0/P0VfS9FCWdyY tOop5WYBzFfPfqHP4Daq1UbZF79lJS0W+7d7VFjgWq4dLI1C9B0H1LAO3TDPIHj+ lbq4RyGEuevl1pFXLQcum34tzlPfv5vrJF6elHWAzxZESRQwuUQ4ZEl3dkdU6P2l h/V9haUG8NHzFHsa+gVABqJ+HbNYeh6U8ve313PB/7kYtCG3ECQuKMouVQkTdNTE yh96FvKQcfqLGEdbLl9F4FyMAD2LVCQZsJeflBYQjXoMJWI/UDW5EJewxosx6ltG OizhQFY7VYnTSdv5PLevfaT0b+qQ5VJ7kNGdyRo+jjtReN8jt/Nr/ZOu7kgx2e2V fDtGfOdEe/3Hc2ZkxhdAP4q/mw17feiEC+ngbHhmtdvGO+Zm02lOwcfVb3vURTHf Pgb74iYpEioxMSlmeNjeHXeo2zPOsAfZDKv1jTuExEkrEZRKAZQ= =Bfnc -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBMACgkQ7ZfpDmKq fjRUzxAAvpQHbranZRCN7Kf5XHR+0oQEio4zDl0ETg/dXmndWUN360JwHIcmzGQR H6XHIPihZX/iBq9R+1gzYDijRagWGJ4YgUnp9qJ9GnM2Xj7+DNkTBjuy+p5fMXU2 /tofAxlaJx4Mb1C7BDLuRc4jtU+36VxCvycwOyEYocngOapOGr/7xooTgYsT6BdR UcxdM6E+M/9PR8Mocz7PrVGyA3QanUp/tLtw6Q7s43Ch9E4W7TTX1T9tVF2b/9Ka 5PmamLEUVBpo0Ia4ofydr0W41sU4A0WRfVu9VjwikNbSJ7Vkw7hEWcgR6aH+GfCN 2ZfGq7JMPhJh3oWuNOTYx6h2ySS3EgRXo3x+4ktm2UIdublCnjzaXl45Hokuqu2F 9RzNeSDc5S1obh72SeALH3FymeeI/dUk3nNqZbM1UvxrJtICn6xcbGA5g78ItExb BOK19dLzkAo8dduBrBRFo7gZ1wB5hudJn5xeY4jsh1Q6lcnYKdWk6k7DcnirNuJG NkbvSlXq+83zxT6DpZXlCpN8qRV6crFcGSq1UUbpX2bRmkqdvmuAOwfdEjqLoH54 fMHPMBSszzaJdMyGmFM7VaJYWmH/I5mUZHQmT+XagL7ZDjGgwMNsoeCGKPBa7vLx lQZU9rwMgqWBm+LimwaZRJrXAoNgk1O+xeYvjNg4cUmiJOgy2wI= =XYNS -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmNFtBQACgkQ7ZfpDmKq fjSNbQ/9FMWPzYHrbPVJH6IZjnfbz0Zc1XeZTDZLvK6BEARPy2fs7/8hWlvuSpz3 nPSIyK3gZyEyd88xSgkzpvf6AvbYRz/KN+6ntOTq1tYoxIcRcqEG8MFqDQ0ZhQuK EqzqGFZHwZbCR4iiZXxiCC7SqX7kRs/rGdXjCZPas/lUn1wkAKoG9oF0JlNCZn8e TdipevHL0AkuG2/mRHTV3r2NAQcs9MTOd0UJyA2gRBDL/BU02jhmaqm13kjsdAEl 5/K8c/o1jGpiuq5nm0fMMMtvnemdu6vWsY8rfbTl9UUKu421Ky6CZ1qVjG0jsGf9 12W5poAbnNQwqxuCCu66QIbwl6CKS3qveSaEvfKMg1OKF1Zc8B3bxVG/oXgAWNo2 jDl/RaTrUVDQC2fxIJjJTHJjwZRAeBH+J8iy3gnuZqeZUvXZLibiIeVCVUfTa5Mf 2ZwxuNcIjY05Ox4ldlAgSmy4ozzRRl8J7X5YoNKR+/H1Nc+t6pzJELCkA+cqXO6c dyBUk7imH08zy+J3EpujEJhFG1s3dunKr0TA494wT8xlXgZm0PNIjz3P4pgsWbUc IWeVvlGhlOOMaIug2JroYGM3yFiyDdcXo3olelZFqAukakQxTb8XFiJGuFtq+USg Hxn09bCLS2BCf8ut3T1TO8g8CF/rAFIASVPvpAZK4fCHOIq+Kq8= =Ttyr -----END PGP SIGNATURE-----

1 0

Re: [tz] What's your idea of a perfect date?
by dpatte Oct. 11, 2022

Oct. 11, 2022

In Canada, the official method for today is 11/10/2022, except if you are a programmer, or from Quebec, where 2022-10-11 (ISO style) is more common. But I sometimes get cheques (checks) from the USA which for today would be 10/11/2022. So here at least, we see cheques with all 3 formats. Most Canadians no longer use cheques - now I see why. US chains (Walmart) often print their receipts in the US format, but Canadian businesses generally use Canadian or ISO format. Its a huge headache if you have a small business and count your pennies on your receipts at tax time - especially if your corp year end is not Dec 31st. 'Was this receipt for last tax year or this tax year'. I personally convinced Ottawa International Airport to convert their displays to ISO format. Their original display software was setup with the USA format. ----- Original Message ----- From: Fred Gleason via tz [mailto:tz@iana.org] To: "Tz Database IANA" <tz(a)iana.org> Sent: Tue, 11 Oct 2022 11:59:10 -0400 Subject: Re: [tz] What's your idea of a perfect date? On Oct 11, 2022, at 11:40, Brooks Harris via tz <tz(a)iana.org> wrote: I once had a check from a UK client (wait, I guess it must have been a cheque?) with a date like "19-7-2015". My American bank would not accept it because the date made no sense to them. It took phone calls and a visit to the bank to sort it out. :-) Even weirder (from a strictly parochial American POV) is a convention I’ve seen in German documents from the the early/mid-twentieth century (and perhaps today?), where the year would be expressed in Roman numerals. Thus: s/19-7-1932/19-7-XXXII/. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | The nice thing about standards is that there are so many of them | | to choose from. | | | | -- Andrew S. Tanenbaum | |---------------------------------------------------------------------|

2 1

What's your idea of a perfect date?
by Brooks Harris Oct. 11, 2022

Oct. 11, 2022

5 7

Regarding email subject "What's your idea of a perfect date?" -Brooks
by Brooks Harris Oct. 11, 2022

Oct. 11, 2022

My apologies for the email with subject "What's your idea of a perfect date?". It has only a .jpg, so it looks very much like spam or phish, as John Hawkinson pointed out to me. I didn't think of that, sorry. Its just a joke I thought the list might find amusing. -Brooks

1 0

Wrong timezone Information provided
by Markus Torshizi Moghaddam Oct. 11, 2022

Oct. 11, 2022

Hello, some weeks ago the timezone data for Europe/Luxembourg changed on your side and a "Link Europe/Brussels Europe/Luxembourg" was added to https://data.iana.org/time-zones/tzdb/europe. This is wrong and results in the wrong timezone for Luxembourg and the wrong calculated time within Outlook and other applications. Can you please fix this. Thanks Best, Markus Torshizi Moghaddam Markus Torshizi Moghaddam Head of Customer Service markus.torshizi-moghaddam(a)cituro.com<mailto:markus.torshizi-moghaddam@cituro.com> Peter-Dörfler-Straße 30 | 86199 Augsburg Tel. +49 821 999 739 40 www.cituro.com/<https://www.cituro.com/> cituro GmbH, Amtsgericht Augsburg, HRB 36662 Geschäftsführung: Florian Heymel, Angie Wodarczyk [cid:image001.png@01D8D95B.2C271600]<https://www.cituro.com/> [cid:image002.png@01D8D95B.2C271600]<https://www.instagram.com/cituro_booking/> [cid:image003.png@01D8D95B.2C271600] <https://www.facebook.com/cituroDACH/> [Ein Bild, das Text, Transport, Axt, Rad enthält. Automatisch generierte Beschreibung] <https://twitter.com/cituroDACH> [Ein Bild, das Text, ClipArt enthält. Automatisch generierte Beschreibung] <https://www.xing.com/pages/cituro-gmbh> [cid:image006.png@01D8D95B.2C271600] <https://www.linkedin.com/company/cituro/> Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail.

7 12

New Yorker article on David Mills and NTP
by scs＠eskimo.com Oct. 7, 2022

Oct. 7, 2022

Readers of this list may be interested in this article: "The Thorny Problem of Keeping the Internet's Time" https://www.newyorker.com/tech/annals-of-technology/the-thorny-problem-of-k… There are a few bobbles: the author seems a bit confused over whether NTP is an Internet RFC or a piece of software, and whether NTP is the IETF's only concern. And the New Yorker's predilection for diereses in English is rather comically distracting when ritually applied to the phrase "Coordinated Universal Time". Nevertheless, a nice read, covering both the technical issues and the people involved, with a particularly touching portrait of Mills himself.

14 23

Re: [tz] New Yorker article on David Mills and NTP
by dpatte Oct. 6, 2022

Oct. 6, 2022

I follow numerous astronomy lists, and there is serious discussion at the IAU (International Astronomical Union) to get rid of leap seconds altogether, and possibly replace them by something else, perhaps leap minutes (or even leap hours) - making them far less common. I believe they expect to make a decision soon, though they have been discussing it for years and had planned to make a decision 2 or 3 years ago. In this case we would add or drop a minute (or hour), when UT1 and UTC were more than a half-minute (or half-hour) out of sync. The concept with hours is that it would work more like a day-light savings transition, and named UTC1, UTC2, etc. Had this been done originally, there would have been no leap-second transitions up to now at all, in fact. ----- Original Message ----- From: Fred Gleason via tz [mailto:tz@iana.org] To: "Time Zone Database discussion" <tz(a)iana.org> Sent: Tue, 4 Oct 2022 13:05:49 -0400 Subject: Re: [tz] New Yorker article on David Mills and NTP On Oct 4, 2022, at 12:07, Steve Allen via tz <tz(a)iana.org> wrote: The implementation of time in computing systems is fragile because itis based on an unrealistic notion that clocks are always right andnever need to be reset. I suspect that one of the primary reasons that such time resets have been so fraught (and hence bitterly opposed by many ‘operations’ type folks) is their relative rarity. There have been only 27 leap seconds introduced since 1972, which means that deployed systems rarely have to cope with one and thus get the inevitable bugs identified and shaken out. It would almost be beneficial if such an event would occur at least once per annum, to allow the ‘reset’ logic to be regularly exercised. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | There cannot be a crisis next week. My schedule is already full. | | | | -- Henry Kissinger | |---------------------------------------------------------------------|

13 19

new update to Asia/Amman TZ
by obadeh.alqatawna＠orange.com Oct. 6, 2022

Oct. 6, 2022

Dears in IANA Organization Good day, Our government here in Jordan has just announced to keep working with GMT +3 TZ all the year in Jordan and here is the official news (Arabic version) https://petra.gov.jo/Include/InnerPage.jsp?ID=225894&lang=ar&name=news we need your support on this by having a new version of tz file that includes this update. Thanks in advance. Best Regards Obadeh Al-Qatawna IN & VAS Operations Team Leader - Orange Jordan Mobile: +962 7 7659 8434 [cid:image001.png@01D8D974.02A74520] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

3 4

Syria adopting "Permanent DST"
by Steffen Thorsen Oct. 6, 2022

Oct. 6, 2022

Various Syrian sources say Syria is adopting year-round DST, starting this autumn. However, some areas are not controlled by the Syria government, and therefore not affected by this. Some quotes (translations are not perfect!) From https://www.sana.sy/?p=1754885 "The Cabinet decided to adopt summer time throughout the year and abolish winter time." >From https://www.alsouria.net/%D8%AD%D9%83%D9%88%D9%85%D8%A9-%D8%A7%D9%84%D9%86%… "The Council of Ministers in the regime’s government decided to adopt daylight saving time throughout the year. During its weekly session, in the presence of Prime Minister Hussein Arnous, today, Tuesday, the Council decided to cancel the winter time, which has been in place for decades in Syria. [...] permanent adoption of daylight saving time." From https://www.enabbaladi.net/archives/607812 "This [the decision] came after the weekly government meeting today, Tuesday 4 October [...]" "The decisions of the regime’s government to delay and advance the clock only apply to the areas under its control, while the northern countryside of Aleppo, which is administratively controlled by Turkey, depends on keeping daylight saving time during all months of the year, as is the case in Turkey, and the reason is due to direct relations with the Turkish state in the field of trade exchange. Public institutions and crossings. Thus, daylight saving time will remain in these two control areas." From https://sourpress.net/?p=170398 "In a statement to Al-Watan, the head of the Astronomical Society in Syria, Muhammad Al-Asiri, considered that this decision has great benefits on the level of energy savings, as well as on the economic level, especially tourism." We will soon publish an English summary in our time zone news section: https://www.timeanddate.com/news/time/ Best regards, Steffen Thorsen - timeanddate.com

2 1

Permanent DST in Jordan
by Even Scharning Oct. 6, 2022

Oct. 6, 2022

The government of Jordan has decided to observe permanent daylight saving time according to this source: https://www.arabiaweather.com/en/content/a-government-decision-to-install-d… Even Scharning Time.is - exact time for any time zone https://time.is/

1 1