To what extent does this complement vs duplicate pytz.utc?

@jbrockmendel pytz has a whole different thing going on, but UTC is so simple that basically all implementations will have the same properties. This version has some fast paths for dateutil-specific stuff (like checking ambiguities), but will work the same as pytz.utc. Of course, there's no way to make pytz.utc is dateutil.tz.UTC or dateutil.tz.UTC is datetime.timezone.UTC, but that's fine. This will mostly make it slightly cheaper to use UTC from dateutil (no need to construct a new instance or even call the constructor now), and move us down the road to a one-object-per-zone model.

@abalkin Any thoughts on this? Not sure who else would understand the implications of this well enough to review.

This looks like a no-brainer optimization. There are several code paths in the datetime module where having the same tzinfo rather then just equal TZ objects saves several calls to utcoffset() methods.

@abalkin Thanks. That's pretty much what I thought. This is the least controversial of the singletons anyway. I'm going to try and come up with an interface for the others that's not totally nuts but ports these "fast path" qualities to the other types (particularly tzfile), I imagine the details of that one will be more important.