On Fri, May 21, 2010 at 7:26 AM, STINNER Victor <report@bugs.python.org> wrote:
..
>>  ... If the tzinfo of the datetime object does not match the
>> system TZ used by mktime, the result will be quite misleading.
>
> Can you suggest a possible fix to take care of the timezone information? I don't know how to use that.

I believe it should be something like this:

from claendar import timegm
def datetime_totimestamp(dt):
    return timegm(dt.utctimetuple()), dt.microsecond)

Note the following comment in the documentation for tzinfo.fromutc():
"An example of a time zone the default fromutc() implementation may
not handle correctly in all cases is one where the standard offset
(from UTC) depends on the specific date and time passed, which can
happen for political reasons.  The default implementations of
astimezone() and fromutc() may not produce the result you want if the
result is one of the hours straddling the moment the standard offset
changes."  I have not tested the above code and it may not work for
non-trivial time-zones.

Still a few questions remain:

1. Should absence of tzinfo imply local timezone or UTC?
2. Given that datetime.fromtimestamp() takes an optional tz argument,
should totimestamp() do the same and use given tz for naive datetime
objects?
3. Should there be a toutctimestamp()?

I believe at this stage we need a python implementation of a prototype
answering these questions and a unit test that would demonstrate how
the prototype would work with nontrivial timezones.