Howard Hinnant's Time Zone Database Parser
I didn’t see a mention of Howard Hinnant’s Time Zone Database Parser (https://howardhinnant.github.io/date/tz.html); did I miss it or is it something worthwhile to add to your list on tz-link.html? -- Scott
On 12/3/19 12:36 PM, Scott Nelson wrote:
I didn’t see a mention of Howard Hinnant’s Time Zone Database Parser (https://howardhinnant.github.io/date/tz.html)
It's currently the 4th bullet in the "Other tz compilers" section: https://data.iana.org/time-zones/tz-link.html#compilers
A passage from https://howardhinnant.github.io/date/tz.html that may bear investigation appears below. @dashdashado You can also customize the build by defining macros (e.g. on the command line) as follows... AUTO_DOWNLOAD If AUTO_DOWNLOAD is 1 then first access to the timezone database will install it if it hasn't been installed, and if it has, will use the remote API to install the latest version if not already installed.
On 12/3/19 3:12 PM, Arthur David Olson wrote:
If |AUTO_DOWNLOAD| is |1| then first access to the timezone database will install it if it hasn't been installed, and if it has, will use the remote API to install the latest version if not already installed.
You're right, that's somewhat concerning, as iana.org is not set up to handle HTTPS requests from a lot of clients. Perhaps Howard can be talked into making his parser's default URL point somewhere else (GitHub?) instead of to iana.org. I'll CC: this message to him. Also, although that parser scrapes the current version number from <https://www.iana.org/time-zones>, that web page's format is not standardized and might change. It would be more reliable to get the latest version number from <https://data.iana.org/time-zones/data/version>, or to get the latest version (including its version number) from <https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.
On Dec 3, 2019, at 6:33 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 12/3/19 3:12 PM, Arthur David Olson wrote:
If |AUTO_DOWNLOAD| is |1| then first access to the timezone database will install it if it hasn't been installed, and if it has, will use the remote API to install the latest version if not already installed.
You're right, that's somewhat concerning, as iana.org is not set up to handle HTTPS requests from a lot of clients. Perhaps Howard can be talked into making his parser's default URL point somewhere else (GitHub?) instead of to iana.org. I'll CC: this message to him.
Also, although that parser scrapes the current version number from <https://www.iana.org/time-zones>, that web page's format is not standardized and might change. It would be more reliable to get the latest version number from <https://data.iana.org/time-zones/data/version>, or to get the latest version (including its version number) from <https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz>.
The end-game here is this library has been voted into the C++20 working draft, to be provided by the std::lib vendors. And without the AUTO_DOWNLOAD feature. Each platform will provide the database as Linux/Mac/BSD do now. http://eel.is/c++draft/#time As C++20 becomes more available, my library will be obsoleted by the std implementation. It is a planned obsolesce. The AUTO_DOWNLOAD will functionality will fade into the rearview mirror. But do be aware that the IANA timezone database (not the tools) has now effectively become the provider for an ISO standard. So try not to get too crazy with changing things. :-) Howard
* Howard Hinnant:
The end-game here is this library has been voted into the C++20 working draft, to be provided by the std::lib vendors. And without the AUTO_DOWNLOAD feature. Each platform will provide the database as Linux/Mac/BSD do now.
As C++20 becomes more available, my library will be obsoleted by the std implementation. It is a planned obsolesce. The AUTO_DOWNLOAD will functionality will fade into the rearview mirror.
I think I have commented on this before. The API assumes that time zone have names that identify them, which is generally not true. On GNU/Linux, the system time zone is the tzdata blob in /etc/localtime, and you cannot in general determine a name from that. Particularly not a name that you can use to set TZ and get back the same blob or even the same time zone. I suspect we could make up a fake name like SYSTEM for this case. It's not clear to me whether the expected implementation of the time_zone * object returned from tzdb::current_zone() is one that automatically reloads time zone information as it becomes available (like the POSIX interfaces on GNU/Linux do). In other words, there is no need for reload_tzdb() to do anything in order to update the current time zone data in a process. The definition of struct tzdb with its public data members is really strange. Is it expected that in order to look up leap seconds, applications look at leap vector? Then it is impossible to implement automatic reloading of leap seconds, which would be disappointing. Thanks, Florian
participants (5)
-
Arthur David Olson -
Florian Weimer -
Howard Hinnant -
Paul Eggert -
Scott Nelson