From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from deimos.uberspace.de (deimos.uberspace.de [185.26.156.152]) by sourceware.org (Postfix) with ESMTPS id 993BC3858412 for ; Mon, 14 Feb 2022 13:21:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 993BC3858412 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jdoubleu.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jdoubleu.de Received: (qmail 24242 invoked by uid 989); 14 Feb 2022 13:21:14 -0000 Authentication-Results: deimos.uberspace.de; auth=pass (plain) From: jdoubleu Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Support non-POSIX TZ strings Message-Id: Date: Mon, 14 Feb 2022 14:21:13 +0100 To: newlib@sourceware.org X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Rspamd-Bar: + X-Rspamd-Report: BAYES_HAM(-0.00013) MV_CASE(0.5) MIME_GOOD(-0.1) URI_COUNT_ODD(1) X-Rspamd-Score: 1.399869 Received: from unknown (HELO unkown) (::1) by deimos.uberspace.de (Haraka/2.8.28) with ESMTPSA; Mon, 14 Feb 2022 14:21:14 +0100 X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, BODY_8BITS, HTML_MESSAGE, KAM_DMARC_STATUS, KAM_SHORT, MSGID_FROM_MTA_HEADER, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2022 13:21:17 -0000 Hello, I stumbled upon an issue with some TZ strings not handled as expected by = newlib's tzset() function. The tzset functions expects the string stored in the TZ environment = variable to follow the POSIX format as described here: = https://sourceware.org/newlib/libc.html#tzset = (or = https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html = ). However, the glibc implementation extends the format and additionally = allows =E2=80=98<[+|-]hh[:mm[:ss]]>=E2=80=99 in the format (compare = https://www.man7.org/linux/man-pages/man3/tzset.3.html = ). It seems like = the timezone database (zoneinfo) provided by the IANA = (https://www.iana.org/time-zones ) = adopted that format; or at least the zic compiler generates these = strings in the zoneinfo files for most systems. That leads to the timezone for "America/Argentina/Buenos_Aires=E2=80=9D = to be "<-03>3=E2=80=9D, as can be seen in this dump = https://raw.githubusercontent.com/nayarsystems/posix_tz_db/master/zones.cs= v = or a linux system: `tail -n 1 = /usr/share/zoneinfo/America/Argentina/Buenos_Aires`. Some more background information can be found here = https://github.com/esp8266/Arduino/issues/8423 = and here = https://github.com/esp8266/Arduino/issues/7690 = . One way to approach this is for the user to just replace the = incompatible part of the string with a valid timezone identifier, as = proposed by https://github.com/esp8266/Arduino/pull/7699 = . Since the timezone identifier (e.g. `PST`, `PDT`, `CET`, =E2=80=A6) is = not really used elsewhere by newlib, this should not be a problem, as = far as I can imagine. On the other hand, some ports implemented a proper parsing: = https://github.com/earlephilhower/newlib-xtensa/pull/14 = . Now my question is whether the extended format should be support by = newlib? Is this desired behaviour and would you accept code = contributions for that matter? Kind Regards =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 jdoubleu