
Jon Skeet wrote:
Windows ... *does* allow you to specify a time zone and exclude DST from that. Anyone wanting to mimic that behaviour but using the tz data can *only* do it if they know the DST component of the overall offset.
No, the existing API suffices for that. For example, you can scan forward to the next time that doesn't have tm_isdst set, and use its UTC offset. I've done that sort of thing. Although this is just a heuristic and might not match user expectations in rare cases, that's also true for what Microsoft Windows does.
- Some platforms *do* consume tzdata directly, and expose the STD/DST components of the overall offset, and are likely to continue doing so.
That's fine, as long as they don't care whether the STD-vs-DST offset is reliable -- it appears they don't, or there'd have been complaints already. And in that case developers of these platforms shouldn't worry much about any changes that involve only the STD-vs-DST offset. It's the sort of change that a regression-tester might need to deal with, but users won't care about and so should be low priority. If the above analysis is wrong and users really care about that offset even though it's not supported by tzdata, then the platforms in question can maintain their own specialized databases and regression suites. It's not something the tz project itself needs to spend its limited resources on.
The man page for zic documents the tz data format, but not in enough detail for a compliant implementation
It'd be helpful to fix that. Any ambiguities should be clarified (or documented as being explicitly ambiguous), as was done in commit 2fab66aa164365209e47af24b2337b7c2ffdbe5c. This shouldn't require a complete rewrite.
If modifying zdump to add an extra flag is deemed an appropriate course of action, do we have any volunteers to do so?
I can volunteer to change zdump but it's not clear yet what needs to be changed. First we'd need to design a good format for regression testing, and document that format. This hasn't been done yet, and will take some thinking. Existing format proposals haven't ensured that the zdump output should contain everything visible to the API.