I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & t

I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & time library in the past). One of such problems is to keep the database up to date, which is nothing but trivial. I'm very confident that the OS-level time zone data is the only database you can be reasonably sure that it's likely up to date, and different OSes expose (sometimes accidentally) different bits of data. Any other solutions are not very automated and tend to drift, I've seen systems where pytz or Java's TZUpdater neglected for a while. I hoped TZDIST [1] to be a thing, but it is not widespread enough, to say the least. In this sense PEP 615 is not exactly the solution but a stopgap; it essentially admits that we can't exactly solve this problem, but we can at least include the existing half-solution into the batteries. [1] https://www.rfc-editor.org/rfc/rfc7808.html https://www.rfc-editor.org/rfc/rfc7808.html