== How to convert a time string in GMT to seconds since the epoch

Recently, I've run into a situation where I have an ASCII string
representing a time, expressed in UTC/GMT, and I want to convert it to
the standard Unix representation of seconds since the epoch.
It turns out that there are some interesting issues involved (well,
in my opinion).

Doing this for a time string in local time is a snap: _[[time
http://www.python.org/doc/current/lib/module-time.html]].strptime()_
will convert the ASCII time string to Python's version of C's ((struct
tm)), and then _[[time]].mktime()_ will turn it into seconds.
However, _time.mktime()_ specifically always uses local
time for the conversion; there is no option to have
it use GMT. To use GMT, you need to use _[[calendar
http://www.python.org/doc/current/lib/module-calendar.html]].timegm()_
instead.

(To the documentation's credit, there is a mention
of this at the bottom of the [[time module
http://www.python.org/doc/current/lib/module-time.html]], although it is
somewhat obscure and easy to miss. (I did the first time around.))

_timegm()_ is somewhat out of place in the [[calendar module
http://www.python.org/doc/current/lib/module-calendar.html]]; its
documentation even says that it's an 'unrelated but handy function'.
So why isn't it in the [[time module]] instead, where it logically
belongs? It's probably because the CPython interpreter makes it hard
to have a module that integrates C and Python code.

The _timegm()_ function is a simple bit of Python. However, the [[time
module]] is pretty much a thin wrapper around the C library's time
functions, and so is written in C. A version of _timegm()_ redone in C
would be annoyingly more complex, and the existing Python version cannot
easily be shoved into a C module. You can shim Python functions into
existing modules, but the trick is getting it to happen automatically
when people do '_import time_' (without going the route of the socket
module, where the real socket module is actually something called
((_socket))).

(While it would also be out of place in a wrapper module, this isn't
something programmers using the module should really have to care about.
What's implemented by the C library and what's implemented in C by the
Python runtime is an implementation detail.)