Removing use of pytz module / implementing our own UTC.

[dhermes]

This was inspired by #1009.

Our methods for signing strings with credentials / crypto will likely be moved into oauth2client, so this is a pre-emptive move to avoid having pytz as a dependency for oauth2client.

As an added benefit, we avoid having pytz as a dependency, which helps for people wanting to use gcloud-python on App Engine.

/cc @nathanielmanistaatgoogle

[tseaver]

No problem with this one overall. I wonder if our local UTC should be an alias of pytz.utc, IFF pytz is importable (to avoid having more than one global for the zone).

[dhermes]

@tseaver RE: default to using pytz, default to ours. Good call!

Code reviews are so useful 😄 I totally overlooked that and it's totally the right way to go.

[tseaver]

I figured that dropping pytz was really FBO users who never care about timezones at all: those who do will want it, anyway.

[dhermes]

Yeah for sure.

[dhermes]

@tseaver I re-pushed the initial commit. Sorry I finished it awhile ago but forgot to push.

Wanted to actually test the case that pytz was installed, but it was being too big a PITA to deal with sys.modules. WDYT?

[tseaver]

We could add a tox stanza that didn't install it.

[dhermes]

What is that?

[tseaver]

Oops, I inverted it in my mind: we could add a stanza that tests it w/ pytz installed, e.g.:

[testenv:py27_w_extras]deps =
{[testenv]deps}
pytz

[dhermes]

Can we punt on it for this PR and fix address it after?

[tseaver]

Sure.

The only thing I see which might be gating is we have no explicit test coverage for the _UTC class: do we need it? If not, go ahead and merge.

[dhermes]

I added it to test__helpers.py, been in here for awhile.

[tseaver]

LGTM