- tz - lists.iana.org

Request for Change of Time Zone Name from Asia/Ho_Chi_Minh to Asia/Ha_Noi
by viet le July 4, 2024

July 4, 2024

Dear Sir/Madam, I am writing to formally request a change in the naming of the time zone for Viet Nam in your database. Currently, the time zone is listed as "Asia/Ho_Chi_Minh." However, I would like to propose that this be updated to "Asia/Ha_Noi" to reflect the official and more widely recognized name of the time zone. Hà Nội, as the capital city of Viet Nam, is the administrative and political center of the country. It holds significant historical, cultural, and socio-economic importance. Consequently, using Hà Nội as the reference point for the country's time zone would be more appropriate and align with international standards and practices. The change from "Asia/Ho_Chi_Minh" to "Asia/Ha_Noi" would not only reflect the official naming conventions but also aid in reducing confusion among users and developers who rely on accurate and standardized time zone data. This adjustment would bring consistency and clarity to the representation of Viet Nam's time zone in global systems. I kindly ask that IANA consider this request and take the necessary steps to implement the change. Your attention to this matter and efforts to ensure accurate representation in the time zone database are greatly appreciated. Thank you for your time and consideration. I look forward to your favorable response. Sincerely, Viet Le

6 5

Mongolia
by Heitor David Pinto July 4, 2024

July 4, 2024

Hello, Sources about time zones in Mongolia seem to list one of two conflicting configurations. The first configuration, mentioned in a comment to the TZ database in 1999, citing a Mongolian government website, lists the provinces of Bayan-Ölgii, Khovd and Uvs in UTC+7, and the rest of the country in UTC+8. The second configuration, mentioned in a comment to the database in 2001, lists Bayan-Ölgii, Khovd, Uvs, Govi-Altai and Zavkhan in UTC+7, Dornod and Sükhbaatar in UTC+9, and the rest of the country in UTC+8. The first configuration is still mentioned by several Mongolian travel agencies: https://www.adventurerider.mn/en/page/about_mongolia http://www.naturetours.mn/nt/mongolia.php https://www.newjuulchin.mn/web/content/7506?unique=fa24a0f6e96e022a3578ee51… It also matches these flight schedules in 2013: http://web.archive.org/web/20130722023600/https://www.hunnuair.com/en/timet… The flight times imply that the airports of Uliastai (Zavkhan), Choibalsan (Dornod) and Altai (Govi-Altai) are in the same time zone as Ulaanbaatar, and Khovd is one hour behind. It also matches a Mongolian news article about the election in 2017: https://mongolia.gogo.mn/r/806d6 The second configuration was mentioned by an official of the Mongolian standards agency in an interview in 2014: https://ikon.mn/n/9v6 And it's still listed by the Mongolian aviation agency: https://ais.mn/files/aip/eAIP/2023-12-25/html/eSUP/ZM-eSUP-23-04-en-MN.html The TZ database used the first configuration until 2001, when it switched to the second configuration, under the assumption that its sources were more reliable. In 2008, based on sources indicating that Choibalsan actually used UTC+8, the database changed Dornod and Sükhbaatar to UTC+8, but only from 2008 on, and maintained Govi-Altai and Zavkhan in UTC+7. This resulted in a mix of the two configurations that is not supported as a whole by any source. Based on all the above sources, I believe that the first configuration is what is actually observed in Mongolia and has been so all along, at least since 1999. The second configuration closely matches the ideal time zone boundaries at 97.5°E and 112.5°E but it doesn't seem to be used in practice. So I suggest the following: 1. In zone.tab, remove Govi-Altai and Zavkhan from Asia/Ulaanbaatar, assuming that they have always used the same time as Ulaanbaatar, or create a new zone Asia/Uliastai showing Govi-Altai and Zavkhan in UTC+8 since at least 1999. 2. Remove the zone Asia/Choibalsan or make it an alias of Asia/Ulaanbaatar, assuming that it has always used the same time as Ulaanbaatar, or list its change from UTC+9 to UTC+8 since at least 1999 instead of 2008. Regards,Dave | | Virus-free.www.avg.com |

2 2

error Portugal 1980
by Alois Treindl July 2, 2024

July 2, 2024

I think there is an error in TZ, regarding begin of DST in Portugal in 1980. A user of my website pointed it out. file europe has > Rule Port 1978 only - Oct 1 0:00s 0 - > Rule Port 1979 1982 - Sep lastSun 1:00s 0 - > Rule Port 1980 only - Mar lastSun 0:00s 1:00 S > Rule Port 1981 1982 - Mar lastSun 1:00s 1:00 S > Rule Port 1983 only - Mar lastSun 2:00s 1:00 S But Observatório Astronómico de Lisboa http://oal.ul.pt/hora-legal/legislacao-sobre-a-hora-legal/ has in document Tabela com a definição anual da Hora Legal portuguesa desde 1911 https://oal.ul.pt/documentos/2018/01/hl1911a2018.pdf > 1980 Hora do meridiano de Greenwich até à 1 hora do dia 6 de Abril, > instante > em que foi adiantada de 60 minutos, tendo-se regressado à hiora do meri- > diano de Greenwich às 2 horas do dia 28 de Setembro (Portaria nº 69/80) > I attach a patch file

4 12

[PROPOSED] More documentation updates for POSIX.1-2024
by Paul Eggert June 16, 2024

June 16, 2024

Be more careful when documenting tm_zone, tm_gmtoff, tzname, etc., in the light of POSIX.1-2024 etc. --- Makefile | 8 ++++-- newctime.3 | 79 ++++++++++++++++++++++++--------------------------- newstrftime.3 | 14 ++++----- newtzset.3 | 55 +++++++++++++++++++++++++++++++---- 4 files changed, 100 insertions(+), 56 deletions(-) diff --git a/Makefile b/Makefile index 99f2f56b..d6d66a1f 100644 --- a/Makefile +++ b/Makefile @@ -358,7 +358,9 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ # # -DHAVE_TZNAME=0 # do not support "tzname" # # -DHAVE_TZNAME=1 # support "tzname", which is defined by system library # # -DHAVE_TZNAME=2 # support and define "tzname" -# # to the "CFLAGS=" line. "tzname" is required by POSIX.1-1988 and later. +# # to the "CFLAGS=" line. Although "tzname" is required by POSIX.1-1988 +# # and later, its contents are unspecified if you use a geographical TZ +# # and the variable is planned to be removed in a future POSIX edition. # # If not defined, the code attempts to guess HAVE_TZNAME from other macros. # # Warning: unless time_tz is also defined, HAVE_TZNAME=1 can cause # # crashes when combined with some platforms' standard libraries, @@ -369,7 +371,9 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ # # -DUSG_COMPAT=1 # support, and variables are defined by system library # # -DUSG_COMPAT=2 # support and define variables # # to the "CFLAGS=" line; "timezone" and "daylight" are inspired by Unix -# # Systems Group code and are required by POSIX.1-2008 and later (with XSI). +# # Systems Group code and are required by POSIX.1-2008 and later (with XSI), +# # although their contents are unspecified if you use a geographical TZ +# # and the variables are planned to be rmeoved in a future edition of POSIX. # # If not defined, the code attempts to guess USG_COMPAT from other macros. # # # # To support the external variable "altzone", add diff --git a/newctime.3 b/newctime.3 index ccc19748..d19fd25b 100644 --- a/newctime.3 +++ b/newctime.3 @@ -9,8 +9,6 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .el .ds - \- .B #include <time.h> .PP -.BR "extern char *tzname[];" " /\(** (optional) \(**/" -.PP .B [[deprecated]] char *ctime(time_t const *clock); .PP /* Only in POSIX.1-2017 and earlier. */ @@ -114,17 +112,6 @@ The function corrects for the time zone and any time zone adjustments (such as Daylight Saving Time in the United States). -After filling in the -.q "tm" -structure, -.B localtime -sets the -.BR tm_isdst 'th -element of -.B tzname -to a pointer to a string that's the time zone abbreviation to be used with -.BR localtime 's -return value. .PP The .B gmtime @@ -294,21 +281,43 @@ from UT, with positive values indicating east of the Prime Meridian. The field's name is derived from Greenwich Mean Time, a precursor of UT. .PP -In +In platforms conforming to POSIX.1-2024 the .B "struct tm" the .B tm_zone and .B tm_gmtoff -fields exist, and are filled in, only if arrangements to do -so were made when the library containing these functions was -created. -Similarly, the -.B tzname -variable is optional; also, there is no guarantee that -.B tzname -will -continue to exist in this form in future releases of this code. +fields exist, and are filled in. +For +.B localtime_rz +and +.B mktime_rz +the storage lifetime of the strings addressed by +.B tm_zone +extends until the corresponding +.B timezone_t +object is freed via +.BR tzfree . +For the other functions the lifetime extends until the +.I TZ +environment variable changes state and +.B tzset +is then called. +.PP +As a side effect, the +.BR ctime , +.B localtime +and +.B mktime +functions also behave as if +.B tzset +were called. +The +.B ctime_r +and +.B localtime_r +functions might (or might not) also behave this way. +This is for compatibility with older platforms, as required by POSIX. .SH FILES .ta \w'/usr/share/zoneinfo/posixrules\0\0'u /etc/localtime local timezone file @@ -322,11 +331,11 @@ continue to exist in this form in future releases of this code. 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), -newtzset(3), -time(2), -tzfile(5) +.BR getenv (3), +.BR newstrftime (3), +.BR newtzset (3), +.BR time (2), +.BR tzfile (5). .SH NOTES The return values of .BR asctime , @@ -336,20 +345,6 @@ and .B localtime point to static data overwritten by each call. -The -.B tzname -variable (once set) and the -.B tm_zone -field of a returned -.B "struct tm" -both point to an array of characters that -can be freed or overwritten by later calls to the functions -.BR localtime , -.BR tzfree , -and -.BR tzset , -if these functions affect the timezone information that specifies the -abbreviation in question. The remaining functions and data are thread-safe. .PP The diff --git a/newstrftime.3 b/newstrftime.3 index 11e37ae8..a9997a09 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -398,7 +398,7 @@ also behaves as if were called. This is for compatibility with older platforms, as required by POSIX; it is not needed for -.BR tzset 's +.BR strftime 's own use. .SH "RETURN VALUE" If the conversion is successful, @@ -428,11 +428,11 @@ conversion and the number of seconds since the Epoch cannot be represented in a .c time_t . .SH SEE ALSO -date(1), -getenv(3), -newctime(3), -newtzset(3), -time(2), -tzfile(5) +.BR date (1), +.BR getenv (3), +.BR newctime (3), +.BR newtzset (3), +.BR time (2), +.BR tzfile (5). .SH BUGS There is no conversion specification for the phase of the moon. diff --git a/newtzset.3 b/newtzset.3 index 4708106d..661fb25b 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -15,6 +15,14 @@ tzset \- initialize time conversion information .PP .B void tzset(void); .PP +/\(** Optional and obsolescent: \(**/ +.br +.B extern char *tzname[]; +.br +.B extern long timezone; +.br +.B extern int daylight; +.PP .B cc ... \*-ltz .fi .SH DESCRIPTION @@ -341,6 +349,22 @@ if the implied call to fails, .B tzset falls back on UT. +.PP +As a side effect, the +.B tzset +function sets some external variables if the platform defines them. +It sets +.BR tzname [0] +and +.BR tzname [1] +to pointers to strings that are time zone abbreviations to be used with +standard and daylight saving time, respectively. +It also sets +.B timezone +to be the number of seconds that standard time is west of the Prime Meridian, +and +.B daylight +to be zero if daylight saving time is never in effect, non-zero otherwise. .SH "RETURN VALUE" If successful, the .B tzalloc @@ -379,8 +403,29 @@ and 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), -newstrftime(3), -time(2), -tzfile(5) +.BR getenv (3), +.BR newctime (3), +.BR newstrftime (3), +.BR time (2), +.BR tzfile (5). +.SH NOTES +Portable code should not rely on the contents of the external variables +.BR tzname , +.B timezone +and +.B daylight +as their contents are unspecified (and do not make sense in general) +when a geographical TZ is used. +In multithreaded applications behavior is undefined if one thread accesses +one of these variables while another thread invokes +.BR tzset . +A future version of POSIX is planned to remove these variables; +callers can instead use the +.I tm_gmtoff +and +.I tm_zone +members of +.B struct tm, +or use +.B strftime +with "%z" or "%Z". -- 2.43.0

2 2

[PROPOSED 1/3] Fix typo when making .txt man pages
by Paul Eggert June 12, 2024

June 12, 2024

* Makefile (MANTXTS): Fix typo: missing ‘:’. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c00eb317..344bb8ed 100644 --- a/Makefile +++ b/Makefile @@ -1054,7 +1054,7 @@ zdump.8.txt: zdump.8 zic.8.txt: zic.8 $(MANTXTS): workman.sh - LC_ALL=C sh workman.sh $(@.txt=) >$@.out + LC_ALL=C sh workman.sh $(@:.txt=) >$@.out mv $@.out $@ # Set file timestamps deterministically if possible, -- 2.43.0

1 2

[PROPOSED] SUPPORT_C89 now defaults to 1, not 0
by Paul Eggert June 8, 2024

June 8, 2024

Although POSIX requires this, I didn’t notice it until today. * Makefile, NEWS, localtime.c: Mention this. * private.h (SUPPORT_C89): Default to 1, not 0. --- Makefile | 5 +++-- NEWS | 4 ++++ localtime.c | 5 +++-- private.h | 17 ++++++++++------- 4 files changed, 20 insertions(+), 11 deletions(-) diff --git a/Makefile b/Makefile index 97a88535..c00eb317 100644 --- a/Makefile +++ b/Makefile @@ -263,8 +263,9 @@ LDLIBS= # -DRESERVE_STD_EXT_IDS if your platform reserves standard identifiers # with external linkage, e.g., applications cannot define 'localtime'. # -Dssize_t=long on hosts like MS-Windows that lack ssize_t -# -DSUPPORT_C89 if the tzcode library should support C89 callers+ -# However, this might trigger latent bugs in C99-or-later callers. +# -DSUPPORT_C89=0 if the tzcode library should not support C89 callers +# Although -DSUPPORT_C89=0 might work around latent bugs in callers, +# it does not conform to POSIX. # -DSUPPORT_POSIX2008 if the library should support older POSIX callers+ # However, this might cause problems in POSIX.1-2024-or-later callers. # -DSUPPRESS_TZDIR to not prepend TZDIR to file names; this has diff --git a/NEWS b/NEWS index 6b71212c..5238cb9e 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,7 @@ Unreleased, experimental changes The code now conforms to RFC 8536 for early timestamps. Support POSIX.1-2024, which removes asctime_r and ctime_r. Assume POSIX.2-1992 or later for shell scripts. + SUPPORT_C89 now defaults to 1. Improve historical data for Portugal and possessions. Changes to data @@ -60,6 +61,9 @@ Unreleased, experimental changes can overrun user buffers. If you still need them, add -DSUPPORT_POSIX2008 to CFLAGS. + The SUPPORT_C89 option now defaults to 1 instead of 0, fixing a + POSIX-conformance bug introduced in 2023a. + tzselect now assumes POSIX.2-1992 or later, as practical porting targets now all support this. Also, tzselect uses some features from POSIX.1-2024 if available. diff --git a/localtime.c b/localtime.c index c9f0d1a8..7e3fd149 100644 --- a/localtime.c +++ b/localtime.c @@ -182,8 +182,9 @@ static int lcl_is_set; ** objects: a broken-down time structure and an array of char. ** Thanks to Paul Eggert for noting this. ** -** This requirement was removed in C99, so support it only if requested, -** as support is more likely to lead to bugs in badly written programs. +** Although this requirement was removed in C99 it is still present in POSIX. +** Follow the requirement if SUPPORT_C89, even though this is more likely to +** trigger latent bugs in programs. */ #if SUPPORT_C89 diff --git a/private.h b/private.h index 0c91a252..19d7f7d6 100644 --- a/private.h +++ b/private.h @@ -19,19 +19,22 @@ /* PORT_TO_C89 means the code should work even if the underlying compiler and library support only C89 plus C99's 'long long' - and perhaps a few other extensions to C89. SUPPORT_C89 means the - tzcode library should support C89 callers in addition to the usual - support for C99-and-later callers; however, C89 support can trigger - latent bugs in C99-and-later callers. These macros are obsolescent, - and the plan is to remove them along with any code needed only when - they are nonzero. A good time to do that might be in the year 2029 + and perhaps a few other extensions to C89. + + This macro is obsolescent, and the plan is to remove it along with + associated code. A good time to do that might be in the year 2029 because RHEL 7 (whose GCC defaults to C89) extended life cycle support (ELS) is scheduled to end on 2028-06-30. */ #ifndef PORT_TO_C89 # define PORT_TO_C89 0 #endif + +/* SUPPORT_C89 means the tzcode library should support C89 callers + in addition to the usual support for C99-and-later callers. + This defaults to 1 as POSIX requires, even though that can trigger + latent bugs in callers. */ #ifndef SUPPORT_C89 -# define SUPPORT_C89 0 +# define SUPPORT_C89 1 #endif #ifndef __STDC_VERSION__ -- 2.43.0

2 1

[PROPOSED 00/12] Assume POSIX.2-1992
by Paul Eggert June 1, 2024

June 1, 2024

For many years we have maintained code in tzselect and Makefile intended to port to older platforms that predate POSIX.2-1992. The only remaining such platform that is still supported by its supplier is Solaris 10 (2005), which has a shell and related tools that are still pre-POSIX by default, although POSIX variants are available. However, I recently discovered that Solaris 10’s own copy of tzselect now uses POSIX.2-1992 features and is based on the POSIX variants. Now that even Oracle has abandoned its pre-POSIX environment for TZDB, it’s time for us to follow suit. This series of patches updates the Makefile and tzselect shell script to assume POSIX.2-1992 or later. This simplifies maintenance and speeds up the code a bit. Paul Eggert (12): Assume POSIX.2 and eschew ‘expr’ Prefer $(CMD) to `CMD` in Makefile Prefer $PWD to $(pwd) in Makefile Avoid subshells when possible Assume POSIX.2 command substitution * tzselect.ksh: Assume POSIX.2 $PWD. * tzselect.ksh: Assume POSIX.2 awk. Avoid some subshells in tzselect Avoid an awk invocation via $'...' Use ‘export VAR=VAL’ syntax Avoid crash in Solaris 10 /usr/xpg4/bin/make Port ! to Solaris make .gitignore | 4 +- Makefile | 343 +++++++++++++++++++++++++-------------------------- NEWS | 9 ++ checknow.awk | 2 +- tzselect.ksh | 112 +++++++---------- workman.sh | 3 +- 6 files changed, 231 insertions(+), 242 deletions(-) -- 2.45.1

1 12

[PROPOSED] difftime isn’t pure either
by Paul Eggert May 28, 2024

May 28, 2024

See <https://sourceware.org/bugzilla/show_bug.cgi?id=31808#c1>. * private.h (difftime): No longer pure. --- private.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/private.h b/private.h index cacbe444..0c91a252 100644 --- a/private.h +++ b/private.h @@ -702,7 +702,7 @@ DEPRECATED_IN_C23 char *ctime(time_t const *); char *asctime_r(struct tm const *restrict, char *restrict); char *ctime_r(time_t const *, char *); #endif -ATTRIBUTE_PURE double difftime(time_t, time_t); +double difftime(time_t, time_t); size_t strftime(char *restrict, size_t, char const *restrict, struct tm const *restrict); # if HAVE_STRFTIME_L -- 2.45.1

1 0

Unicode CLDR supplemental/windowsZones.xml update? -Brooks Harris
by Brooks Harris May 28, 2024

May 28, 2024

Does someone know if the Unicode CLDR ../supplemental/windowsZones.xml has been updated? Following the best links I know to find: Unicode CLDR Overview https://cldr.unicode.org/index/downloads/cldr-45 Downloads https://cldr.unicode.org/index/downloads GitHub Tag https://raw.githubusercontent.com/RobThree/TimeZoneMapper/master/TimeZoneMa… This file says it corresponds with TzDb 2021a. Yet other notes say Windows zone were updated to TzDb 2024a: CLDR 45 Release Note https://cldr.unicode.org/index/downloads/cldr-45 Timezones Deprecating timezones that are no longer in zone.tab (America/Nipigon, ...) New Windows timezone mappings Was this file not actually updated or am I looking in the wrong place? Thanks, -Brooks

4 6

[PROPOSED 1/4] More updates to GCC_DEBUG_FLAGS for GCC 14
by Paul Eggert May 27, 2024

May 27, 2024

* Makefile (GCC_DEBUG_FLAGS): Omit -fno-common, as it is now the default. Omit -Wuninitialized as it’s implied by -Wall. Omit -Wno-address and -Wno-type-limits as they don’t seem to be needed with GCC 14. --- Makefile | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 6b093013..4d2ac1cf 100644 --- a/Makefile +++ b/Makefile @@ -313,7 +313,7 @@ GCC_INSTRUMENT = \ -fsanitize=undefined -fsanitize-address-use-after-scope \ -fsanitize-undefined-trap-on-error -fstack-protector # Omit -fanalyzer from GCC_DEBUG_FLAGS, as it makes GCC too slow. -GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ +GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 \ $(GCC_INSTRUMENT) \ -Wall -Wextra \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ @@ -332,10 +332,9 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Wsuggest-attribute=const -Wsuggest-attribute=format \ -Wsuggest-attribute=malloc \ -Wsuggest-attribute=noreturn -Wsuggest-attribute=pure \ - -Wtrampolines -Wundef -Wuninitialized -Wunused-macros -Wuse-after-free=3 \ + -Wtrampolines -Wundef -Wunused-macros -Wuse-after-free=3 \ -Wvariadic-macros -Wvla -Wwrite-strings \ - -Wno-address -Wno-format-nonliteral -Wno-sign-compare \ - -Wno-type-limits + -Wno-format-nonliteral -Wno-sign-compare # # If your system has a "GMT offset" field in its "struct tm"s # (or if you decide to add such a field in your system's "time.h" file), -- 2.43.0

2 5

Re: [tz] Unicode CLDR supplemental/windowsZones.xml update? -Brooks Harris
by Paul Eggert May 27, 2024

May 27, 2024

On 2024-05-26 12:44, Brooks Harris wrote: > Hi Pail, > On 2024-05-26 03:37 PM, Paul Eggert wrote: >> On 2024-05-26 12:30, Brooks Harris via tz wrote: >>> What is the best procedure to obtain the latest windowsZones.xml? >> >> https://github.com/unicode-org/cldr/blob/main/common/supplemental/windowsZo… > > This file is identical to the old one I have and does not reflect the > commits you referred me to. That's not a file, it's a bunch of info about the file. The info includes the file contents and a bunch of other stuff. If you just want the file, click the Raw button. >>> Is there a record of earlier versions? >> https://github.com/unicode-org/cldr/commits/main/common/supplemental/window… >> >> These are reachable from the earlier URL I emailed. > > Right, but no version of windowsZones.xml I can find has those commits > applied. ? Those changes are visible to me via that URL. Anyway, try clicking the "Raw" button. It should give you this URL: https://raw.githubusercontent.com/unicode-org/cldr/main/common/supplemental… and I see the changes there too.

4 7

[PROPOSED 1/4] Update GCC_DEBUG_FLAGS for GCC 14
by Paul Eggert May 25, 2024

May 25, 2024

* Makefile (GCC_DEBUG_FLAGS): Add -Wflex-array-member-not-at-end, -Wmissing-variable-declarations. --- Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 3f550b3f..a72fb2ea 100644 --- a/Makefile +++ b/Makefile @@ -315,10 +315,11 @@ GCC_DEBUG_FLAGS = -DGCC_LINT -g3 -O3 -fno-common \ -Walloc-size-larger-than=100000 -Warray-bounds=2 \ -Wbad-function-cast -Wbidi-chars=any,ucn -Wcast-align=strict -Wdate-time \ -Wdeclaration-after-statement -Wdouble-promotion \ - -Wduplicated-branches -Wduplicated-cond \ + -Wduplicated-branches -Wduplicated-cond -Wflex-array-member-not-at-end \ -Wformat=2 -Wformat-overflow=2 -Wformat-signedness -Wformat-truncation \ -Wimplicit-fallthrough=5 -Winit-self -Wlogical-op \ - -Wmissing-declarations -Wmissing-prototypes -Wnested-externs \ + -Wmissing-declarations -Wmissing-prototypes \ + -Wmissing-variable-declarations -Wnested-externs \ -Wnull-dereference \ -Wold-style-definition -Woverlength-strings -Wpointer-arith \ -Wshadow -Wshift-overflow=2 -Wstrict-overflow \ -- 2.45.1

1 3

[PROPOSED] Sub-second history for Maputo and Zurich
by Paul Eggert May 25, 2024

May 25, 2024

* africa (Africa/Maputo), europe (Europe/Zurich): Add #STDOFF comments for two zones with well-sourced standard time that was not an integral number of seconds away from UT. This does not change the TZif output files. --- africa | 5 +++-- europe | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/africa b/africa index 695d66ed..4f0d1e7b 100644 --- a/africa +++ b/africa @@ -1101,11 +1101,11 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # Zambia # Zimbabwe # -# From Paul Eggert (2024-04-09): +# From Paul Eggert (2024-05-24): # The London Gazette, 1903-04-03, page 2245, says that # as of 1903-03-03 a time ball at the port of Lourenço Marques # (as Maputo was then called) was dropped daily at 13:00:00 LMT, -# corresponding to 22:49:41.7 GMT; round this to UT+2:10:18. +# corresponding to 22:49:41.7 GMT, so local time was +02:10:18.3. # Conversely, the newspaper South Africa, 1909-02-09, page 321, # says the port had just installed an apparatus that communicated # "from the controlling clock in the new Observatory at Reuben Point ... @@ -1116,6 +1116,7 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # For lack of better info, list 1909 as the transition date. # # Zone NAME STDOFF RULES FORMAT [UNTIL] + #STDOFF 2:10:18.3 Zone Africa/Maputo 2:10:18 - LMT 1909 2:00 - CAT diff --git a/europe b/europe index 9ea14914..2f180e64 100644 --- a/europe +++ b/europe @@ -3486,8 +3486,8 @@ Zone Atlantic/Canary -1:01:36 - LMT 1922 Mar # Las Palmas de Gran C. # but if no one is present after 11 at night, could be postponed until one # hour before the beginning of service. -# From Paul Eggert (2013-09-11): -# Round BMT to the nearest even second, 0:29:46. +# From Paul Eggert (2024-05-24): +# Express BMT as 0:29:45.500, approximately the same precision 7° 26' 22.50". # # We can find no reliable source for Shanks's assertion that all of Switzerland # except Geneva switched to Bern Mean Time at 00:00 on 1848-09-12. This book: @@ -3526,6 +3526,7 @@ Rule Swiss 1941 1942 - May Mon>=1 1:00 1:00 S Rule Swiss 1941 1942 - Oct Mon>=1 2:00 0 - # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Zurich 0:34:08 - LMT 1853 Jul 16 # See above comment. + #STDOFF 0:29:45.500 0:29:46 - BMT 1894 Jun # Bern Mean Time 1:00 Swiss CE%sT 1981 1:00 EU CE%sT -- 2.43.0

2 2

Deprecating POSIX Zones to Links?
by Justin Grant May 23, 2024

May 23, 2024

Hi TZ friends - I'm one of the volunteers working on ECMAScript's time zone strategy. We had a question: of all the legacy Zone names in TZDB, why have a few of them like "WET" and "EST5EDT" been retained as Zones, while the rest of the legacy names like "GB-Eire" and "Jamaica" have all been turned into Links pointing to some other Zone? What was special about the Zones below that caused them to stay as Zones? EST MST HST EST5EDT CST6CDT MST7MDT PST8PDT WET CET MET EET Regardless of the history behind these 11 Zone names, would there be interest in accepting a PR that turns these Zones into Links? I'm asking because ECMAScript's time zone enumeration API is specified to only return Zone names, but ECMAScript implementations in Safari and Chrome have long omitted the Zones above from their enumeration API because they create redundant and confusing results for end users. We'd like to align the specification to web reality, and ideally make these changes upstream in TZDB (if that would be welcome). Here's the mappings that we're currently considering in ECMAScript. We used the TZ approach of preferring the largest city for each of the DST-using legacy Zones. Although any other mappings would be OK with us, so let me know if you think there are more appropriate mappings. EST => Etc/GMT+5 MST => Etc/GMT+7 HST => Etc/GMT+10 EST5EDT => America/New_York CST6CDT => America/Chicago MST7MDT => America/Denver PST8PDT => America/Los_Angeles WET => Europe/Lisbon CET => Europe/Berlin MET => Europe/Berlin EET => Europe/Kyiv Thanks, Justin Grant

3 7

[PROPOSED 1/2] Don’t be so sure about leap seconds going away
by Paul Eggert May 14, 2024

May 14, 2024

* NEWS, theory.html (Leap seconds): * tz-link.html (Precision timekeeping): Use less-sure wording about leap seconds discontinuance, since the situation is still murky. --- NEWS | 2 +- theory.html | 10 +++++----- tz-link.html | 1 + 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 5c2cd1e5..e5db26b4 100644 --- a/NEWS +++ b/NEWS @@ -322,7 +322,7 @@ Release 2023a - 2023-03-22 12:39:33 -0700 To improve tzselect diagnostics, zone1970.tab's comments column is now limited to countries that have multiple timezones. - Note that leap seconds are planned to be discontinued by 2035. + Note that there are plans to discontinue leap seconds by 2035. Release 2022g - 2022-11-29 08:58:31 -0800 diff --git a/theory.html b/theory.html index 50e9ee4d..4cb293da 100644 --- a/theory.html +++ b/theory.html @@ -1278,11 +1278,11 @@ between now and the future time. <p> Leap seconds were introduced in 1972 to accommodate the difference between atomic time and the less regular rotation of the earth. -Unfortunately they caused so many problems with civil -timekeeping that they -are <a href="https://www.bipm.org/en/cgpm-2022/resolution-4">planned -to be discontinued by 2035</a>. -Despite their impending obsolescence, a record of leap seconds is still +Unfortunately they have caused so many problems with civil +timekeeping that there are +<a href="https://www.bipm.org/en/cgpm-2022/resolution-4">plans +to discontinue them by 2035</a>. +Even if these plans come to fruition, a record of leap seconds will still be needed to resolve timestamps from 1972 through 2035. </p> diff --git a/tz-link.html b/tz-link.html index c6d96101..aaab7555 100644 --- a/tz-link.html +++ b/tz-link.html @@ -1129,6 +1129,7 @@ discontinuous adjustments be made to UTC for at least a century. The World Radiocommunication Conference <a href="https://www.itu.int/dms_pub/itu-r/opb/act/R-ACT-WRC.15-2023-PDF-E.pdf">resolved in 2023</a> to cooperate with this process. +However, there is still no consensus on how exactly to get rid of them. </li> </ul> </section> -- 2.40.1

1 1

manual pages in tzdb
by Alejandro Colomar May 12, 2024

May 12, 2024

Hi Paul, I had in mind something: I would like to cherry-pick all tzdb's commits that affect manual pages into the Linux man-pages git repository, instead of just pasting here snapshots of your manual pages. For that to work, we'd need to agree on a path inside the repository (or I could manually --or with a script-- edit each commit, which would be combersome, and I'd rather avoid). What do you think of moving the pages in the tzdb repository into man/man*/ directories? I see your repository is perfectly flat, so I don't know if there are strong reasons for that, or if it's just innertia. To be explicit, this is what I'd do in tzdb.git: diff --git a/date.1 b/man/man1/date.1 similarity index 100% rename from date.1 rename to man/man1/date.1 diff --git a/newctime.3 b/man/man3/newctime.3 similarity index 100% rename from newctime.3 rename to man/man3/newctime.3 diff --git a/newstrftime.3 b/man/man3/newstrftime.3 similarity index 100% rename from newstrftime.3 rename to man/man3/newstrftime.3 diff --git a/newtzset.3 b/man/man3/newtzset.3 similarity index 100% rename from newtzset.3 rename to man/man3/newtzset.3 diff --git a/time2posix.3 b/man/man3/time2posix.3 similarity index 100% rename from time2posix.3 rename to man/man3/time2posix.3 diff --git a/tzfile.5 b/man/man5/tzfile.5 similarity index 100% rename from tzfile.5 rename to man/man5/tzfile.5 diff --git a/tzselect.8 b/man/man8/tzselect.8 similarity index 100% rename from tzselect.8 rename to man/man8/tzselect.8 diff --git a/zdump.8 b/man/man8/zdump.8 similarity index 100% rename from zdump.8 rename to man/man8/zdump.8 diff --git a/zic.8 b/man/man8/zic.8 similarity index 100% rename from zic.8 rename to man/man8/zic.8 If we do that, then my idea would be to do $ git remote add tzdb git@github.com:eggert/tz.git in my Linux man-pages local repo, and cherry-pick commits '-- man/' from time to time. Does that sound good to you? Have a lovely day! Alex -- <https://www.alejandro-colomar.es/> A client is hiring kernel driver, mm, and/or crypto developers; contact me if interested.

9 20

[PROPOSED] Update some URLs
by Paul Eggert May 9, 2024

May 9, 2024

--- theory.html | 2 +- tz-link.html | 40 +++++++++++++++++++--------------------- 2 files changed, 20 insertions(+), 22 deletions(-) diff --git a/theory.html b/theory.html index 5cb80d99..50e9ee4d 100644 --- a/theory.html +++ b/theory.html @@ -1088,7 +1088,7 @@ an older <code>zic</code>. and <code>localtime_rz</code> and <code>mktime_z</code> are like <code>localtime_r</code> and <code>mktime</code> with an extra <code>timezone_t</code> argument. - The functions were inspired by <a href="https://netbsd.org/">NetBSD</a>. + The functions were inspired by <a href="https://netbsd.org">NetBSD</a>. </li> <li> Negative <code>time_t</code> values are supported, on systems diff --git a/tz-link.html b/tz-link.html index 162d63ce..c6d96101 100644 --- a/tz-link.html +++ b/tz-link.html @@ -81,7 +81,7 @@ C Library</a> (used in title="Berkeley Software Distribution">BSD</abbr></a>, <a href="https://netbsd.org">Net<abbr>BSD</abbr></a>, <a href="https://www.openbsd.org">Open<abbr>BSD</abbr></a>, -<a href="https://www.chromium.org/chromium-os/">Chromium OS</a>, +<a href="https://www.chromium.org/chromium-os/">ChromiumOS</a>, <a href="https://cygwin.com">Cygwin</a>, <a href="https://mariadb.org">MariaDB</a>, <a href="https://en.wikipedia.org/wiki/MINIX">MINIX</a>, @@ -211,7 +211,7 @@ href="https://mm.icann.org/mailman/listinfo/tz">subscribe</a> to it and browse the <a href="https://mm.icann.org/pipermail/tz/">archive of old messages</a>. -<a href="https://tzdata-meta.timtimeonline.com/">Metadata for mailing list +<a href="https://tzdata-meta.timtimeonline.com">Metadata for mailing list discussions</a> and corresponding data changes can be generated <a href="https://github.com/timparenti/tzdata-meta">automatically</a>. </p> @@ -226,7 +226,7 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, +for <a href="https://www.ibm.com/support/pages/aix-time-zone-olson-tzdata-updates"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a @@ -248,7 +248,7 @@ with lines terminated by <a href="https://en.wikipedia.org/wiki/Newline"><abbr title="linefeed">LF</abbr></a>, which can be modified by common text editors such as <a href="https://www.gnu.org/software/emacs/">GNU Emacs</a>, -<a href="https://wiki.gnome.org/Apps/Gedit">gedit</a>, and +<a href="https://gedit-technology.github.io/apps/gedit/">gedit</a>, and <a href="https://www.vim.org">vim</a>. Specialized source-file editing can be done via the <a href="https://packagecontrol.io/packages/zoneinfo">Sublime @@ -400,7 +400,7 @@ variant <a href="https://datatracker.ietf.org/doc/html/rfc6321">xCal</a> title="Extensible Markup Language">XML</abbr></a> format, and a variant <a href="https://datatracker.ietf.org/doc/html/rfc7265">jCal</a> (Internet <abbr>RFC</abbr> 7265) -uses <a href="https://www.json.org"><abbr +uses <a href="https://www.json.org/json-en.html"><abbr title="JavaScript Object Notation">JSON</abbr></a> format.</li> </ul> </section> @@ -440,11 +440,9 @@ transition in the <code><abbr>tz</abbr></code> database.</li> <li>The <a href="https://howardhinnant.github.io/date/tz.html">Time Zone Database Parser</a> is a <a href="https://en.wikipedia.org/wiki/C++">C++</a> parser and -runtime library with <a -href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html">API</a> -adopted by -<a href="https://en.wikipedia.org/wiki/C++20">C++20</a>, -the current iteration of the C++ standard. +runtime library with a <a +href="https://en.cppreference.com/w/cpp/chrono"><code>std::chrono</code> API</a> +that is a standard part of C++. It is freely available under the <abbr title="Massachusetts Institute of Technology">MIT</abbr> license.</li> <li><a id="ICU" href="https://icu.unicode.org">International Components for @@ -467,8 +465,8 @@ freely available under the <abbr>MIT</abbr> license.</li> <li>The <a href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">TZUpdater tool</a> compiles <code><abbr>tz</abbr></code> source into the format used by -<a href="https://openjdk.java.net/">OpenJDK</a> and -<a href="https://jdk.java.net/">Oracle JDK</a>. +<a href="https://openjdk.org">OpenJDK</a> and +<a href="https://jdk.java.net">Oracle JDK</a>. Although its source code is proprietary, its executable is available under the <a href="https://www.oracle.com/a/tech/docs/tzupdater-lic.html">Java SE Timezone Updater License Agreement</a>.</li> @@ -490,7 +488,7 @@ are alternatives to TZUpdater. IANA Updater's license is unclear; ZIUpdater is licensed under the <abbr>GPL</abbr>.</li> <li><a href="https://github.com/MenoData/Time4A">Time4A: Advanced date and time library for Android</a> and -<a href="https://github.com/MenoData/Time4J/">Time4J: Advanced date, +<a href="https://github.com/MenoData/Time4J">Time4J: Advanced date, time and interval library for Java</a> compile <code><abbr>tz</abbr></code> source into a binary format. Time4A is available under the Apache License and Time4J is @@ -516,7 +514,7 @@ many of which also support runtimes lacking the <code>timeZone</code> option. href="https://github.com/formatjs/date-time-format-timezone"><code>Intl.DateTimeFormat</code> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li>The <a href="https://date-fns.org/">date-fns</a> +<li>The <a href="https://date-fns.org">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. It is freely available under the <abbr>MIT</abbr> license.</li> @@ -552,9 +550,9 @@ objects</a> let programs access an abstract view of <code><abbr>tzdb</abbr></code> data, and are designed to replace <a href="https://codeofmatt.com/javascript-date-type-is-horribly-broken/">JavaScript's problematic <code>Date</code> objects</a> when working with dates and times. -<li><a href="https://github.com/JuliaTime/">JuliaTime</a> contains a +<li><a href="https://github.com/JuliaTime">JuliaTime</a> contains a compiler from <code><abbr>tz</abbr></code> source into -<a href="https://julialang.org/">Julia</a>. It is freely available +<a href="https://julialang.org">Julia</a>. It is freely available under the <abbr>MIT</abbr> license.</li> <li><a href="https://github.com/pavkam/tzdb"><abbr>TZDB</abbr> – <abbr>IANA</abbr> Time Zone Database for Delphi/<abbr @@ -565,7 +563,7 @@ as compiled by <a href="https://en.wikipedia.org/wiki/Delphi_(IDE)">Delphi</a> and <a href="https://en.wikipedia.org/wiki/Free_Pascal"><abbr>FPC</abbr></a>. It is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a href="http://pytz.sourceforge.net">pytz – World Timezone +<li><a href="https://pythonhosted.org/pytz/">pytz – World Timezone Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. @@ -649,7 +647,7 @@ that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the <a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. -A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module +A companion <a id="pypi-tzdata" href="https://pypi.org">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> supplies TZif data if the underlying system data cannot be found; it is freely available under the Apache License.</li> @@ -898,7 +896,7 @@ href="https://www.ptb.de/cms/en/fachabteilungen/abt4/fb-44/ag-441/realisation-of of Legal Time in Germany</a>.</dd> <dt>Israel</dt> <dd><a -href="https://tz.cs.huji.ac.il/">Israel Timezone Files</a> +href="https://tz.cs.huji.ac.il">Israel Timezone Files</a> lists official time-change announcements and laws since 1940, almost all in Hebrew.</dd> <dt>Malaysia</dt> @@ -1087,9 +1085,9 @@ is well-defined for sufficiently old timestamps.</li> <code>leap-seconds.list</code>, which lists the currently known leap seconds. The <abbr>IERS</abbr> maintains this file, and a copy is distributed by <code><abbr>tzdb</abbr></code> for use by <abbr>NTP</abbr> implementations like -<a href="https://www.ntp.org/">classic +<a href="https://www.ntp.org">classic <code><abbr title="Network Time Protocol Daemon">ntpd</abbr></code></a> -and <a href="https://ntpsec.org/">NTPsec</a>. +and <a href="https://ntpsec.org">NTPsec</a>. The <code><abbr>tz</abbr></code> database also distributes leap second information in a differently-formatted <code>leapseconds</code> text file, as well as in the "<code>right</code>" configuration in binary form; for -- 2.40.1

1 0

Why is "AEST" the abbreviation for Australia/Sydney in 1900?
by Jonathan Wakely May 9, 2024

May 9, 2024

Given this snippet from tzdata.zi: Z Australia/Sydney 10:4:52 - LMT 1895 F 10 AU AE%sT 1971 R AU 1917 o - Ja 1 2s 1 D R AU 1917 o - Mar lastSu 2s 0 S R AU 1942 o - Ja 1 2s 1 D R AU 1942 o - Mar lastSu 2s 0 S R AU 1942 o - S 27 2s 1 D R AU 1943 1944 - Mar lastSu 2s 0 S R AU 1943 o - O 3 2s 1 D What should the abbreviation be for the zone in, say, 1900? Using glibc I get AEST: TZ=Australia/Sydney date --date="1900-01-01" Mon 1 Jan 00:00:00 AEST 1900 But I don't see any way to get "AEST" from the tzdata and the spec in the zic(8) man page. Prior to 1895 it is "LMT", and then from 1917-01-01 it's "AEDT", and from 1917-03-25 it's "AEST", but none of the Rule lines apply to dates before 1917, so what value of LETTER/S should be used for the AE%sT format in 1900? Glibc solves this by iterating through all the transitions for the AU rule until it finds a valid name for a transition to DST and a valid name for a transition out of DST, and then remembers those two names, which in this case gives AEDT (from 1917-01-01 to 1917-03-25) and AEST (from 1917-03-25 to 1942-01-01). Then when it finds the info for a date in 1900 it looks at the isdst field of struct tm for that date, and picks one of the two remembered names, which gives us "AEST". That seems like the correct result, but nothing in the zic man page (or any other docs I can find) says that is what's supposed to happen. My code for GCC's C++ library is an independent implementation based on the spec, and it has no way to produce "AEST" for 1900. It seems to me that either the spec should to do ... something ... so that a LETTER/S field for the Rule can be found, or there should be a Zone continuation line in the tzdata that explicitly says that Australia/Sydney is always on standard time for the period 1895-02-01 to 1917-01-01 and that the abbreviation is AEST (without any %s that needs to be expanded). So add the second line here: Z Australia/Sydney 10:4:52 - LMT 1895 F 10 - AEST 1917 10 AU AE%sT 1971 R AU 1917 o - Ja 1 2s 1 D R AU 1917 o - Mar lastSu 2s 0 S R AU 1942 o - Ja 1 2s 1 D R AU 1942 o - Mar lastSu 2s 0 S R AU 1942 o - S 27 2s 1 D R AU 1943 1944 - Mar lastSu 2s 0 S R AU 1943 o - O 3 2s 1 D I'm sure this question could also be asked of many other zones, Australia/Sydney just happens to be the one I was testing with and noticed that my code couldn't expand the %s in "AE%sT". Am I missing something that says to use "S" as the LETTER/S field for dates prior to the first DST transition in 1917? What logic do other C libraries use to get "AEST" here?

6 20

Does Egypt spring forward tomorrow at 00:01 not 00:00?
by Paul Eggert April 25, 2024

April 25, 2024

Two recent news reports say that Egyptian clocks spring forward tomorrow at 00:01, not at 00:00 as per TZDB. Both cite Law No. 24 of 2023. Does anybody on this list have access to the text of that Egyptian law? I am unable to find a copy of that law online; <https://guides.loc.gov/law-egypt/legislative> points me at <https://www.egypt.gov.eg/english/laws/default.aspx> but www.egypt.gov.eg (41.33.95.166) is inaccessible to me (no packets seem to get through). I am mildly inclined to think that the distinction between 00:00 and 00:01 is being done by the news sources in question and not by the actual law. However, if someone can get a copy of the legislation that should be definitive. Here are the two sources giving spring-forward and fall-back times that differ by one minute from TZDB: * Egypt prepares to implement daylight saving time last Friday of April, Egypt Today, 2024-04-22 <https://www.egypttoday.com/Article/1/131747/Egypt-prepares-to-implement-day…> "... the current time used will be advanced by sixty minutes, starting at 12 midnight (00:01 a.m.) on Friday, April 26, until the end of the last Thursday of October at (23:59 p.m.)." * Belal Nawar, Daylight Savings in Egypt Starts on 26 April, Egyptian Streets, 2024-04-25 <https://egyptianstreets.com/2024/04/25/daylight-savings-in-egypt-starts-on-…> "The clock will be advanced by sixty minutes, starting from midnight (00:01 a.m.) on Friday 26 April, and will revert to standard time at the end of the last Thursday of October, precisely at 11:59 p.m. (23:59 p.m.)." I also see a couple of reports that we were one minute off in fall 2023: * Shereif Barakat, Egypt Bids Farewell to Daylight-Saving Time Tomorrow, Egyptian Streets, 2023-10-25 <https://egyptianstreets.com/2023/10/25/egypt-bids-farewell-to-daylight-savi…>. * Daylight Saving Time in Egypt Will End One Minute Before October 27th Scene Now, 2023-10-26 <https://scenenow.com/Buzz/Daylight-Saving-Time-in-Egypt-Will-End-One-Minute…>. On the other hand, other sources simply give transitions on the hour or on the day. Examples include <https://english.ahram.org.eg/NewsContentP/1/522092/Egypt/Summer-Time-vs-pow…> and <https://cairoscene.com/Buzz/Daylight-Saving-Time-to-Start-in-Egypt-on-Frida…>. In particular <https://www.lexology.com/library/detail.aspx?g=34fe8046-f02b-4af1-a515-30cd…>, in which an Egyptian law firm summarizes Law No. 24 (issued 16 April 2023), merely gives day boundaries. So perhaps the 00:01 and 23:59 business is merely the news sources' trying to avoid confusion.

1 0

Asia/Gaza POSIX TZ string problem
by Z Meng Chen April 22, 2024

April 22, 2024

Hi, We obtained the *tzdata2024a* from IANA. Below is the Rule for *Asia/Gaza* extracted from *tzdata2024a*: * ...* *Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -* *Rule Palestine 2023 only - Apr 29 2:00 1:00 S* *Rule Palestine 2024 only - Apr 20 2:00 1:00 S* *Rule Palestine 2025 only - Apr 12 2:00 1:00 S* ... *Asia/Gaza POSIX TZ string (generated by zic)*: EET-2EEST, M3.4.4/50,M10.4.4/50" The rule specifies that DST in 2024 starts on April 20th. Why then does the POSIX TZ string use M3.4.4? Is this a bug? or is there any other reason? Thanks. Best regards, Meng Chen

3 5

request to update DST info for Timezone: Tehran/Iran
by Vajihe Bitarafan April 16, 2024

April 16, 2024

Hi Dear IANA, I am using some system and I encountered that in some situations Daylight Saving Time is not working correctly. >From 20 March 2023 , DST has been removed from government Policies and So from then there would not be any changes in Time. So Time zone Tehran/IRAN is +3:30 for all days of the year. I hope it will be reflected in timezone databases and I can see the Joda time is updated respectively. Thanks in advance for your help Best regards, Vajiheh Bitarafan

4 4

Vadsø, Norway mayor wants 26-hour days
by Paul Eggert April 15, 2024

April 15, 2024

On March 20 Wenche Pedersen, the mayor of Vadsø municipality, Norway, asked[1] the European Commission to issue a directive allowing Norway to create a separate time zone for the northern part of Norway. Days in the new time zone would contain 26 hours instead of the usual 24. This request is part of the "MOREtime" project. Mayor Pedersen wrote: > ... we aim to celebrate and promote this unique way of life, offering individuals the opportunity to enjoy more quality time engaging in activities such as fishing, hunting, learning new languages, or simply being with loved ones. By having our own certified time zone within the EU, we hope to attract more young people, not only from Norway but also from around the world, to discover and settle in this adventurous area. Recently the mayor's proposal has been covered by several major news organizations. When asked how the 26-hour day would actually work, the mayor replied "We haven't thought a lot about that. The clock will go from 12 to 13 ... and we have to see how this will go. I don't think they're going to say yes so we haven't thought about all the details."[2] Longtime readers of the time zone mailing list might remember that in 2019 a resident of Sommarøy, Norway petitioned his parliamentarian to abolish civil time in his town, something that also made the news.[3] However, the Sommarøy proposal was by a private individual and was easily implementable via tzdata by creating a new UTC or LMT zone with abbreviation "-00" or "LMT", whereas the Vadsø proposal is by the mayor, and would require changes to tzcode and would therefore be considerably harder to support. Although it's unlikely that the Vadsø proposal will go anywhere, it's helpful to think of how timekeeping changes like this might be accommodated by the TZDB project, as similar proposals might happen in the future. I see several ways to implement 26-hour days, falling into two major categories. Category I: Shorten civil-time hours so that there are 26 civil-time hours in a standard-length (SI) day. Four possible ways to do this are: A. Civil-time seconds are 12/13 s (i.e., 12/13 of an SI second, or about 0.923 s), so that civil-time minutes and hours are both 12/13 of their SI counterparts. B. Civil-time seconds are the same as before, but civil-time minutes are 60 * 12/13 s (i.e., about 55.38 s). C. Civil-time seconds and minutes are the same as before, but civil-time hours are 60 * 12/13 min (i.e., about 55.38 SI minutes). D. Civil-time minutes are 60 * sqrt(12/13) s (about 57.65 s), and civil-time hours are 60 * sqrt(12/13) civil-time minutes (i.e., about 57.65 civil-time minutes). Category II: Adjust day lengths so that all or most days contain 26 SI hours. Three possibilities here are: E. Civil-time days are 26 SI hours, and the calendar gradually falls further and further behind the Gregorian calendar. F. Civil-time days are 26 SI hours, but skip every 13th day so that days stay roughly synchronized with the Gregorian calendar. G. At the end of every day, move clocks backward two hours, from 24:00 to 22:00, so that timestamps from 22:00:00 through 23:59:59 repeat. Do this consistently for eleven days, thus moving clocks backward a total of 22 hours. On the twelfth day move clocks forward 22 hours instead, from 24:00 to 22:00 the next day. Repeat this cycle indefinitely. This way, eleven days out of thirteen contain 26 hours, and the next two days combined also contain 26 hours - 24 hours in the twelfth day and 2 hours in the thirteenth. Of these methods something like (G) would be the most compatible with computerized timekeeping, as (G) conforms to POSIX-1.202x Draft 4.1[4] whereas (A) through (F) do not. (G) avoids timestamps like 25:30; G's hours, minutes or seconds are all of the usual lengths; and (G) contains only transitions that are like daylight-saving transitions that computerized timekeeping can already deal with. Although a downside of (G) is that at times the sun will be at its zenith at midnight, I assume Vadsø residents are already accustomed to midnight suns so this disadvantage is relatively minor for them. Another downside of (G) is that clocks will never go "from 12 to 13" as the mayor requested, but given the major technical difficulties of (A) through (F) I hope the mayor would appreciate that (G) may be the best we can practically hope for in today's standardized and computerized world. Unfortunately even (G) would require some changes to tzcode and tzdata to become practical, and it would take many years for these changes to propagate to devices in common use in Vadsø. So, unless Vadsø residents are prepared to change their clocks by hand every day for the next several years, it does not appear that the mayor's proposal will be practical any time soon. I am sending this email to the time zone mailing list, as perhaps someone on the list can think of even better ways to implement the mayor's request. I am also cc'ing this email to Mayor Pedersen to give her a heads-up about this analysis, should it ever be needed in Vadsø. [1]: https://kommunikasjon.ntb.no/files/17848798/18066114/57109/no [2]: https://www.politico.eu/article/norway-arctic-region-asks-eu-commission-for… [3]: https://mm.icann.org/pipermail/tz/2019-June/028154.html [4]: https://www.opengroup.org/austin/

6 5

Kazakhstan Airline Schedules
by Owen Leibman April 14, 2024

April 14, 2024

I have a friend in Kazakhstan whom, thanks to this list, I notified about the recent time change before it was widely known in the country. She says the transition was pretty smooth, but, over a month later, sent me a message, which I pass on (without the attachments showing the discrepancies) as an anecdotal demonstration of how hard it is to get all the pieces in place: Happy eclipse day! I'm sending an update for your friends on time zones and flights. I booked a flight in February to Frankfurt leaving this Wednesday. United says the flight departs 4:20 a.m., but Lufthansa sent me an email saying I could check in for my flight which leaves at 3:20 a.m. Yet another Lufthansa check-in screen and the boarding pass says it leaves at 4:20. Meanwhile FlightAware claims the flight is not leaving till 5:20 a.m. All have the same arrival time of 9 a.m. Nursultan airport website does not list the flight yet. I will let you know which one proves to be right! I think it's 4:20. This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.

2 3

[PROPOSED] Shanks is likely wrong about Maputo switch to CAT
by Paul Eggert April 9, 2024

April 9, 2024

* NEWS: Mention the change, and leave room for future Portugal fixes. * africa (Africa/Maputo): Tweak LMT to match London Gazette, and change CAT transition date to a guess of 1909. --- NEWS | 4 ++++ africa | 19 ++++++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 25d939f1..0d6a1513 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: The main data form now uses %z. + Improve historical data for Portugal and possessions. Changes to data @@ -15,6 +16,9 @@ Unreleased, experimental changes the represented data: the generated TZif files are unchanged. Rearguard form still avoids %z, to support obsolescent parsers. + Some transitions for Portugal and possessions have been changed. + This affects timestamps for Africa/Maputo before 1909. + Asia/Almaty has been removed from zonenow.tab as it now agrees with Asia/Tashkent for future timestamps, due to Kazakhstan's 2024-02-29 time zone change. Similarly, America/Scoresbysund diff --git a/africa b/africa index a731dbee..695d66ed 100644 --- a/africa +++ b/africa @@ -1101,13 +1101,22 @@ Zone Africa/El_Aaiun -0:52:48 - LMT 1934 Jan # El Aaiún # Zambia # Zimbabwe # -# Shanks gives 1903-03-01 for the transition to CAT. -# Perhaps the 1911-05-26 Portuguese decree -# https://dre.pt/pdf1sdip/1911/05/12500/23132313.pdf -# merely made it official? +# From Paul Eggert (2024-04-09): +# The London Gazette, 1903-04-03, page 2245, says that +# as of 1903-03-03 a time ball at the port of Lourenço Marques +# (as Maputo was then called) was dropped daily at 13:00:00 LMT, +# corresponding to 22:49:41.7 GMT; round this to UT+2:10:18. +# Conversely, the newspaper South Africa, 1909-02-09, page 321, +# says the port had just installed an apparatus that communicated +# "from the controlling clock in the new Observatory at Reuben Point ... +# exact mean South African time, i.e., 30 deg., or 2 hours East of Greenwich". +# Although Shanks gives 1903-03-01 for the transition to CAT, +# evidently the port transitioned to CAT after 1903-03-03 but before +# the Portuguese legal transition of 1912-01-01 (see Europe/Lisbon commentary). +# For lack of better info, list 1909 as the transition date. # # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Maputo 2:10:20 - LMT 1903 Mar +Zone Africa/Maputo 2:10:18 - LMT 1909 2:00 - CAT # Namibia -- 2.44.0

1 0

Using %z in FORMAT column of 'europe' etc.
by Paul Eggert April 8, 2024

April 8, 2024

[This is a repost with minor updates of <https://mm.icann.org/pipermail/tz/2024-March/058790.html>. This repost is in a separate email thread, with a clearer "Subject:" line.] The recent glitches with %z-related lines in the Portugal data lead me to think that it's time to start using %z in the main format. For example, instead of this: > # Zone NAME STDOFF RULES FORMAT [UNTIL] > Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada > -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT > -2:00 Port -02/-01 1942 Apr 25 22:00s > -2:00 Port +00 1942 Aug 15 22:00s > -2:00 Port -02/-01 1943 Apr 17 22:00s > -2:00 Port +00 1943 Aug 28 22:00s > -2:00 Port -02/-01 1944 Apr 22 22:00s > -2:00 Port +00 1944 Aug 26 22:00s > -2:00 Port -02/-01 1945 Apr 21 22:00s > -2:00 Port +00 1945 Aug 25 22:00s > -2:00 Port -02/-01 1966 Apr 3 2:00 > -1:00 Port -01/+00 1983 Sep 25 1:00s > -1:00 W-Eur -01/+00 1992 Sep 27 1:00s the 'europe' file should contain this: > # Zone NAME STDOFF RULES FORMAT [UNTIL] > Zone Atlantic/Azores -1:42:40 - LMT 1884 # Ponta Delgada > -1:54:32 - HMT 1912 Jan 1 2:00u # Horta MT > -2:00 Port %z 1966 Apr 3 2:00 > -1:00 Port %z 1983 Sep 25 1:00s > -1:00 W-Eur %z 1992 Sep 27 1:00s This would eventually simplify future maintenance and help avoid similar glitches in the future. For now, the 'rearguard' format would continue to avoid %z in the FORMAT column. It's reasonable to use %z in 'europe' now, as zic has supported %z since release 2015f.

1 1