4 ms·
Pytz handles a certain class of funkiness in TZ changes, but not the one mentioned here. Consider, a user in footopia enters a datetime 3 months from now which
by Stasis5001 10y ago
Pytz handles a certain class of funkiness in TZ changes, but not the one mentioned here. Consider, a user in footopia enters a datetime 3 months from now which is saved in UTC in your database. Then footopia changes their TZ definition. The only way you could get this right is if you also know when the datetime in the database was created. You would need to tell your datetime library the datetime and _when it was created_, and pytz doesn't do that (I don't know any that do, actually).
- guitarbill 10y agoYou'll never get this right, even if you had all of this info, because as mjevans points out[0] to make it work you need to know: > P) The event is at a precise internationally recognized moment (better for co-ordination globally). > R) The event is in local time (like a lunch date) and expected to remain colloquially fixed. In the case you mention, it's somewhat arguable that the burden of changing the colloquially fixed dates (R) falls on the citizens of footopia, in the same way as changing the time of a purely mechanical clock also would. caveat emptor. [0] https://news.ycombinator.com/item?id=13206671 https://news.ycombinator.com/item?id=13206671