On 6/7/21 9:21 AM, Neil Fuller wrote:
To fix this for future releases *safely*, I think downstream code like Android would need metadata at runtime (preferably mastered by TZDB) that indicates whether a zone ID is one of the ones that has flipped its behavior.
Surely it'd have to be more complicated than that, as a single Zone can have negative DST some years, and positive DST other years. See Africa/Windhoek, for example. But perhaps I'm not understanding the problem correctly, as I don't see why tzdb would need to maintain a separate set of data for this issue. Android libraries could have a flag (or multiple versions, or however Android folks like to do software changes) controlling whether an application can tolerate negative DST. If the flag says "negative DST is OK", the libraries can pass through data unscathed. If the flag says "I don't want to see negative DST", then whenever the underlying data says DST is negative, the Android library can swap standard and daylight time and give the swapped info to the app. As I understand it, Android libraries are already doing the latter; if so, all that needs to be added is a flag so that they can do the former. Anyway, I appreciate the info about why rearguard support will be needed for quite some time.