On 2024-01-06 12:45, Guy Harris via tz wrote:
there is no inherent reason why the TZif format, for example, should limit itself to supporting only the date/time functions that POSIX and the C standard currently happen to provide
Although an API *could* support deeper interrogation of TZif details, I doubt whether that'd be a good idea. The distinction between stdoff and tm_gmtoff is not always clear, any extra information you'd extract from the data could well be dubious (certainly there are dubious corners in this part of tzdata now), and improving tzdata and maintaining the result would require unnecessary work. We saw an instance of this sort of thing in America/Nuuk last year. Before 2023d, summer 2023 was marked as daylight saving time, but 2023d changed that to standard time. Although nobody in the real world cared (because it didn't affect UTC offsets or even abbreviations), the change consumed nontrivial maintenance effort. And the only reason the change was needed was because of tm_isdst, a feature that should never have been made visible to users in the first place. I wouldn't want even more unnecessary maintenance make-work to follow from exposing even more unnecessary details to users.