Brian Inglis wrote:
Set when last transition increased offset, clear when last transition reduced offset?
An interesting idea, but if taken literally it would depart from the original intent of tm_isdst in too many cases. For example, it would mean Africa/Lagos would currently have tm_isdst set, because Nigeria's last transition increased the UT offset, when it switched from local mean time to standard time in 1919. I agree with Robert Elz that tm_isdst is vestigial, in the sense that nowadays application uses of it are typically unnecessary or even incorrect. The same goes for its many counterparts in Java, such as the getRawOffset, getDSTSavings, observesDaylightTime, useDaylightTime, and inDaylightTime methods of the java.util.TimeZone class. In hindsight, all these interfaces are mistakes: they attempt to shoehorn civil-timekeeping practices into boxes that too often don't fit, and applications don't really need the interfaces directly anyway. This is underscored by the nature of the bug reports reported so far for this problem: most of them are for test suites (that is, they're testing vestigial interfaces and so are relatively unimportant in and of themselves), and the only application-level bug report showed that the application was clearly wrong in its use of tm_isdst. All this being said, tzdb can't simply ignore these vestigial interfaces, as so much software uses them (albeit incorrectly).