TZ: Issue parsing glibc timezones #12
Comments
d-a-v
added a commit
to esp8266/Arduino
that referenced
this issue
Nov 10, 2020
* TZ: help newlib parser Timezones coded with numeric abbreviations <±nn>±nn<±nn>[±nn][,...] are incorrectly parsed by newlib's TZ parser. Replacing <±nn> occurences by UNK allows newlib's TZ parser to nicely interpret all timezones. Detailed explanation in earlephilhower/newlib-xtensa#12
earlephilhower
added a commit
that referenced
this issue
Nov 11, 2020
Some timezones are now encoded with "<+/-nn>" instead of a text name. Allow those greater-/less-than in the parser. Fixes #12
earlephilhower
added a commit
that referenced
this issue
Nov 11, 2020
Fixes #12 TZ.h can now contain timezone names of the form <[+-]nn> when there is no commonly used timezone abbreviation for the setting. Adjust the tzset function to handle this case by special-casing the name parsing when the first character is a '<'.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ref: esp8266/Arduino#7699
Posix timezone strings defined in current common linux distributions running glibc are sometimes incorrectly parsed by newlib.
Their format starts with
ABRVnn[ABRV[nn]][,...].For example:
GMT0BST,...is London TZ descriptor with two abbreviationsGMTandBST.ABRVis an abbreviation meaning something for humans.BSTmeans "British Summer Time".Such abbreviations are not defined for every timezone around the world. It is said in https://data.iana.org/time-zones/theory.html (source) that :
These numeric offsets are enclosed between
<...>. For example, abbreviation for Sao Paulo TZ is<-03>3(instead of for example validSAOPAULO3).The full path from official definitions starts from the above repository:
zicthe zoneinfo compiler uses files defining timezones on all continents to build most linux distribution's/usr/share/zoneinfo/*files, which are parsed by this tool to produce a csv file used by esp8266/arduino. One will notice that quite a large number of abbreviations are numeric.The issue is that numeric abbreviations like
<-03>3are incorreclty parsed by newlib.On the other hand, it seems that glibc's TZ parser is able to do so despite the fact that numeric abbreviations do not seem to follow posix TZ definition.
Abbreviations values are anyway unused in
esp8266/arduinotime library. To circumvent the parsing issue, numeric abbreviations are(about to be)converted to a posix compliant random string thanks to a script (in the PR referred on top of this message).The text was updated successfully, but these errors were encountered: