- 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