My timezone is set to UTC, which means that the API (apparently) uses the usual shortened version also described in ISO 8601 or the more accessible RFC 3339 section 2, for instance: 2023-05-24T20:43:16Z.
This in turn causes issues with not just the implementation in ext/date (i.e. the std::chrono::parse polyfill due to some compilers like GCC not yet having fully implemented C++20), but the actual definition of the parser as far as I can tell from various places around the internet, among them some documents from people involved in the standards, previews of how the new API is to be used, but probably easiest the cppreference on std::chrono::parse, which describes the format as being a time offset, not mentioning the possible Z suffix for UTC at all for the %z format, which is used in the code:
Which prevents any results from being properly parsed, making all dates the unix epoch of 1970-01-01 and yielding this error message:
Failed to parse date '2023-05-24T20:43:16Z' on site Danbooru
I haven't found anything on how to properly parse RFC 3339 strings using C++ in that regard, but it seems that the corresponding parsing would've to be split into one using the above format and another fallback using something like date::parse("%FT%TZ", t); which would have to hard set the timezone for that result to UTC.
The issue seems to be specifically with the data returned from the Danbooru API, as changing the timezone in the account settings works, changing the local timezone (i.e. running as env TZ=Europe/Vienna ahoviewer) does not change the outcome.
When not using any credentials to log in (i.e. account-specific settings are not active) it works too.
My timezone is set to UTC, which means that the API (apparently) uses the usual shortened version also described in ISO 8601 or the more accessible RFC 3339 section 2, for instance:
2023-05-24T20:43:16Z
. This in turn causes issues with not just the implementation inext/date
(i.e. thestd::chrono::parse
polyfill due to some compilers like GCC not yet having fully implemented C++20), but the actual definition of the parser as far as I can tell from various places around the internet, among them some documents from people involved in the standards, previews of how the new API is to be used, but probably easiest the cppreference onstd::chrono::parse
, which describes the format as being a time offset, not mentioning the possibleZ
suffix for UTC at all for the%z
format, which is used in the code:https://github.com/ahodesuka/ahoviewer/blob/42e16f94b78496e3e346f0d127baa569039a6757/src/booru/site.cc#L863
Which prevents any results from being properly parsed, making all dates the unix epoch of 1970-01-01 and yielding this error message:
I haven't found anything on how to properly parse RFC 3339 strings using C++ in that regard, but it seems that the corresponding parsing would've to be split into one using the above format and another fallback using something like
date::parse("%FT%TZ", t);
which would have to hard set the timezone for that result to UTC.The issue seems to be specifically with the data returned from the Danbooru API, as changing the timezone in the account settings works, changing the local timezone (i.e. running as
env TZ=Europe/Vienna ahoviewer
) does not change the outcome. When not using any credentials to log in (i.e. account-specific settings are not active) it works too.