Hacker News Reader

Comment by charlex815 | Hacker News Reader

I suppose this beats breaking out time delta, but I think it'll be hard for me to see an actual use in my projects that I couldn't accomplish with maybe just a couple extra lines

View on HN

you'd be surprised, the amount of headache-inducing code that timezones can cause, especially when dealing with servers with different locales than your development machine when doing timezone algebra.

This API avoids that problem entirely.

It does not: timezone (TZ) definitions are politicial, inaccurate, and stupid and non versioned.

The problem with TZ is TZ in its core definition.

1) they always change: if you have not updated your TZ since 3 months they are probably inaccurate

2) your TZ definition maybe accurate but they may not have been applied for real in the concerned zone

3) you can have different local time for the same longitude

4) you can have different days on the same longitude ...

5) TZ are not versioned, if the TZ changed between 2 records you may have made, you have inaccurate intervals stored. We do NOT have an API to take TZ change over time in consideration.

6) CEST/DST is breaking the axiom that time is a growing monotonic function

References 8.5.3 TZ in postgresql man https://www.postgresql.org/docs/9.2/static/datatype-datetime...

Computerphile what's wrong with timezones https://www.youtube.com/watch?v=-5wpm-gesOY

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.

> 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

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).

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

Reply on news.ycombinator.com