Stephen Colebourne wrote:
Because applications have APIs that they want to continue to support in a backwards compatible way. Even if everything were deprecated today, those APIs would need to be supported for at least 10 years and probably more.
When and how forcefully to deprecate something really is one of the key questions here. But I think a big part of the disconnect is that, in many people's minds, the isdst-related portions of the TZ API have already been pretty severely deprecated for at least 10 years (maybe even 20). So, quite aside from all the discussions over the specific Ireland case, it's worth asking: If the TZ project isn't already deprecating timezone and tm_isdst, should it be, and how strongly, and using what language in which documents? And what about POSIX? Is there any way of getting them to deprecate those inadequate old interfaces, and perhaps standardize tm_gmtoff while they're at it? Do we know how many programs are using timezone and tm_isdst (and the variable that says "this zone observes DST sometimes", and the other difficult API bits we've been discussing here)? Do we know why they think they have to use them? Is there guidance we can give them to help wean them off them?