- tz - lists.iana.org

[PATCH] Port better to POSIX 'touch'
by Paul Eggert July 26, 2023

July 26, 2023

* Makefile (set-timestamps.out): Use POSIX syntax for 'touch -d' rather than relying on a GNU extension. --- Makefile | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 17e73891..d891f837 100644 --- a/Makefile +++ b/Makefile @@ -988,8 +988,11 @@ set-timestamps.out: $(EIGHT_YARDS) rm -f test.out && \ for file in $$files; do \ if git diff --quiet $$file; then \ - time=`git log -1 --format='tformat:%ct' $$file` && \ - touch -cmd @$$time $$file; \ + time=`TZ=UTC0 git log -1 \ + --format='tformat:%cd' \ + --date='format:%Y-%m-%dT%H:%M:%SZ' \ + $$file` && \ + touch -cmd $$time $$file; \ else \ echo >&2 "$$file: warning: does not match repository"; \ fi || exit; \ -- 2.39.2

2 3

Problem with some timezone data from 2023 w/ Java SimpleTimeZone
by Andreas Haumer July 19, 2023

July 19, 2023

Hi! [I hope this is the right place to report this problem. I reported it on OpenSUSE bugzilla, but was asked to report it upstrem, too. See https://bugzilla.opensuse.org/show_bug.cgi?id=1213470 for my original bugreport] A few days ago I found that with the 2023c timezone database as installed on OpenSUSE LEAP or RedHat Fedora there are two timezones which produce an IllegalArgumentException in the SimpleTimeZone Java class (from OpenJDK 17): "Asia/Gaza" and "Asia/Hebron" The following small Java programm demonstrates the problem: andreas@localhost:~> cat TimeZoneTest.java import java.util.TimeZone; public class TimeZoneTest { public static void main(String[] argv) { for (final String id : TimeZone.getAvailableIDs()) try { TimeZone.getTimeZone(id).toString(); } catch (Exception ex) { System.out.println("TimeZone " + id + " failed: " + ex); } } } Running this programm with a current Java timezone database installed gives the following output: andreas@localhost:~> java TimeZoneTest.java TimeZone Asia/Gaza failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 TimeZone Asia/Hebron failed: java.lang.IllegalArgumentException: Illegal daylight saving value: 0 andreas@localhost:~> rpm -q timezone-java timezone-java-2023c-150000.75.23.1.noarch andreas@localhost:~> java -version openjdk version "17.0.7" 2023-04-18 OpenJDK Runtime Environment (build 17.0.7+0-suse-150400.3.24.1-x8664) OpenJDK 64-Bit Server VM (build 17.0.7+0-suse-150400.3.24.1-x8664, mixed mode, sharing) This is with OpenSUSE LEAP 15.4 and 15.5 I also see the same exceptions with Fedora 37, which also uses a separate 2023c timezone database for Java. Debian based systems (like Debian 11, Debian 12 or Ubuntu 22) run the above program without error. They use the internal tzdb which comes with OpenJDK. It looks like the timezone database contains a 0 for the dstSavings property. The constructor for the SimpleTimeZone Java class wants this calue to be > 0 and throws an IllegalArgumentException if it isn't: public SimpleTimeZone(int rawOffset, String ID, int startMonth, int startDay, int startDayOfWeek, int startTime, int startTimeMode, int endMonth, int endDay, int endDayOfWeek, int endTime, int endTimeMode, int dstSavings) { setID(ID); this.rawOffset = rawOffset; this.startMonth = startMonth; this.startDay = startDay; this.startDayOfWeek = startDayOfWeek; this.startTime = startTime; this.startTimeMode = startTimeMode; this.endMonth = endMonth; this.endDay = endDay; this.endDayOfWeek = endDayOfWeek; this.endTime = endTime; this.endTimeMode = endTimeMode; this.dstSavings = dstSavings; // this.useDaylight is set by decodeRules decodeRules(); if (dstSavings <= 0) { throw new IllegalArgumentException("Illegal daylight saving value: " + dstSavings); } } So: is this a problem with the timezone database or rather a problem with the implementation of the Java SimpleTimeZone class? Thanks! - andreas -- Andreas Haumer *x Software + Systeme | mailto:andreas@xss.co.at Karmarschgasse 51/2/20 | https://www.xss.co.at/ A-1100 Vienna, Austria | Tel: +43-1-6060114-0

3 2

Issue with timezone
by Ty Hanks July 18, 2023

July 18, 2023

Having an issue with timezone ‘America/Bogota’ should be the same as ‘America/NewYork’ but if you pull time based on it from pytz which uses your database. You get the wrong timezone a 3 or 4 hour ahead timezone. Feel free to ask for more testing info if needed .. Thanks

4 3

TZDB 2023c build issues with ARM busybox
by Rajesh Subramanian July 11, 2023

July 11, 2023

Hi Team, I am trying to compile the TZDB in ARM busysbox version: 2023c After compiling the executable during the installation stage, got an error while trying to create the timezone files using tzdata.zi. Could you please help on what is wrong here? make BACKWARD='backward' DESTDIR='/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz' LEAPSECONDS='' PACKRATDATA='' PACKRATLIST='' TZDEFAULT='/etc/localtime' TZDIR='/usr/share/zoneinfo' ZIC='./zic ' LEAPSECONDS= install_data make[1]: Entering directory '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/tz/tz-2023c' ./zic -v -d '/home/rajesh/code/iss/build/ISS-MVL-ARM-IM/niagara-staging/tmp/tz/usr/share/zoneinfo' tzdata.zi *./zic: 1: Syntax error: word unexpected (expecting ")")* make[1]: *** [Makefile:697: install_data] Error 2 File format for the executable: file zic is linked with the expected host architecture. *zic*: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=48cd5d62692908a4f58468f5077d4187fe06c825, not stripped Regards, Rajesh

4 3

Error in Scandinavian tz data
by Anders Rosendahl June 28, 2023

June 28, 2023

Hello! I'm developing an application using the JavaScript Intl API (which is relying on the IANA tz db) for converting between local time and UTC. I started receiving error reports from users about wrong calculations (particularly from Denmark in the 1940's), and I discovered that in some cases daylight saving time was applied in a way not in accordance to historical facts. I investigated the IANA tz database files and I discovered that a change has happened in version 2022b (in the file "europe"). Compared to the earlier version (2022a), 4 zones seem to have their rules removed and instead linked to Europe/Berlin: Link Europe/Berlin Arctic/Longyearbyen Link Europe/Berlin Europe/Copenhagen Link Europe/Berlin Europe/Oslo Link Europe/Berlin Europe/Stockholm This, evidently, is not correct, and will result in erroneous results for these zones. Best wishes, Anders Rosendahl

7 11

Re: [tz] [libc-coord] thread-safe localtime() for an arbitrary timezone
by Paul Eggert June 21, 2023

June 21, 2023

On 2023-06-15 10:03, enh wrote: > any thoughts on either renaming `struct state` (i went with `struct > __timezone_t` to match the typedef to timezone_t for the pointer) or having > a knob for that (i added a `#define state __timezone_t` in the `#if > NETBSD_INSPIRED` in private.h)? why do i care? because tzcode pulls in the > system <time.h>, which is actually fine for the tzcode code, but breaks the > OpenBSD wcsftime(). We could rename 'struct state', but I'm a bit lost as to what the problem is, as I don't see mention of 'state' or 'timezone_t' in openbsd/lib/libc/time/wcsftime.c. Although there is a 'struct state' in openbsd/lib/libc/time/localtime.c I assume you're replacing that with tzcode's localtime.c somehow. User apps (which tzcode is, by default) shouldn't define symbols like __timezone_t because these symbols are reserved to the system. We could easily rename 'struct state' to 'struct timezone_struct' so that you could compile with -Dtimezone_struct=__timezone_t, though I'm still curious about why 'struct state' causes problems. I'll cc this to the tz mailing list to see whether other people there have insight into this issue. For those new to the discussion, the original thread is archived here: https://www.openwall.com/lists/libc-coord/2023/06/14/1

4 14

Iran Time Zone is Incorrect in Your Database
by Mohammad Ahmadian June 2, 2023

June 2, 2023

Hello, Thanks for your service. This year, the Iran government decided to cancel the daylight time zone. So they did not change the time zone to 04:30. It is now 03:30. I updated my tablet via this application to the latest version of your database successfully: https://github.com/meefik/tzupdater But the time zone is wrongly 04:30 again. Please change your database. Let me know what you think and do. Thank you

2 1

Tzdb build issue
by Naveen kumar June 1, 2023

June 1, 2023

Hi Team, I am facing this issue while compiling the tzdata latest version tzdb-2023c.I attached the log for your reference. Thanks, Naveen.

4 9

[PROPOSED] Update tzselect comment
by Paul Eggert June 1, 2023

June 1, 2023

* tzselect.ksh: Update comment, as Oracle has extended the end-of-life date for Solaris 10. --- tzselect.ksh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzselect.ksh b/tzselect.ksh index 9a91acfc..98774c03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -21,7 +21,7 @@ REPORT_BUGS_TO=tz(a)iana.org # MirBSD Korn Shell <http://www.mirbsd.org/mksh.htm> # # For portability to Solaris 10 /bin/sh (supported by Oracle through -# January 2024) this script avoids some POSIX features and common +# January 2025) this script avoids some POSIX features and common # extensions, such as $(...) (which works sometimes but not others), # $((...)), ! CMD, ${#ID}, ${ID##PAT}, ${ID%%PAT}, and $10. -- 2.39.2

2 1

[PATCH] Ask for POSIX-conforming ‘make’
by Paul Eggert May 31, 2023

May 31, 2023

* Makefile (.POSIX): New target. I discovered the need for this when I ran ‘make -n’ and GNU Make executed recipe lines containing $(MAKE) even though they had side effects. When run in POSIX mode, GNU Make won’t execute recipe lines unless they begin with ‘+’. POSIX says the behavior of ‘make’ is undefined unless the Makefile’s first non-comment line has a ‘.POSIX’ target. --- Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Makefile b/Makefile index 8017a14e..da3ee259 100644 --- a/Makefile +++ b/Makefile @@ -1,4 +1,6 @@ # Make and install tzdb code and data. +# Request POSIX conformance; this must be the first non-comment line. +.POSIX: # This file is in the public domain, so clarified as of # 2009-05-17 by Arthur David Olson. -- 2.39.2

1 0