Ran into a little problem today that requires being able to see what timezones (of the Linux-ish America/Toronto, America/Montreal variety) are equivalent to one another.:

#! /usr/bin/env python
"""Stupid little script to find equivalent timezones"""
import pytz, pprint, pickle, datetime
all_timezones = [pytz.timezone(name) for name in pytz.all_timezones]
def search():
    now = datetime.datetime.now()
    set = {}
    for zone in all_timezones:
        # Note: do not use _tzname or _utcoffset, that way lies madness!
        name = zone.tzname( now )
        offset = zone.utcoffset( now )
        set.setdefault( (offset,name), []).append( zone )
    return set 

pprint.pprint( search() )

You can imagine a case where this didn't work, where some nation actually has different timezones than their neighbours, with the tzdata database saying they are in EST for 3 months a year, and then EDT for another 3, then in SPEC for the other 6, but hopefully those cases will describe themselves with SPECS SPECD and SPEC for the most part.  Basically, this is a heuristic to get a quick data-massage finished.

The reason I mention this is actually that comment in the middle.  It is very tempting, when loading up pytz in ipython to start poking around and using _tzname or _utcoffset... problem is, those are often useless... e.g. Asia/Chungking will show up as "LMT", which is actually a Local Mean Time value (not a real timezone, if you ask me, but oh well).  Until you localize a particular datetime (e.g. now), you have a reference to the first record in the timezone's definition (_tzinfos), rather than anything meaningful to you in thinking about timezone identities.

Anyway, if someone has a better mechanism, happy to hear about it, for now, this seems like it should work for this particular massage.