2 ms·

The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

by DasIch 10y ago

nicpottier 10y ago
Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is. There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now. Then again you probably have all sorts of DST bugs if you have places in your code that do that.
- masklinn 10y ago
  > Pretty sure pytz will hand you the appropriate timezone for a given date. Correct, or more precisely for a given timezone it will use the correct offset depending on the date being converted: >>> format_datetime(datetime.datetime(2011, 12, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full') Wednesday, 14 December 2011 at 23:12:18 Apia Daylight Time >>> format_datetime(datetime.datetime(2012, 1, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full') Sunday, 15 January 2012 at 23:12:18 Apia Daylight Time
- 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 ago
    You'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

The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

by DasIch 10y ago

The TZ database has versions and you could at least in theory expose that at a higher level in libraries.

Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is. There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now. Then again you probably have all sorts of DST bugs if you have places in your code that do that.

masklinn 10y ago
> Pretty sure pytz will hand you the appropriate timezone for a given date. Correct, or more precisely for a given timezone it will use the correct offset depending on the date being converted: >>> format_datetime(datetime.datetime(2011, 12, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full') Wednesday, 14 December 2011 at 23:12:18 Apia Daylight Time >>> format_datetime(datetime.datetime(2012, 1, 15, 10, 5, 18, tzinfo=berlin).astimezone(samoa), 'full') Sunday, 15 January 2012 at 23:12:18 Apia Daylight Time
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 ago
  You'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