On Mon, Jun 4, 2012 at 3:21 PM, Alexandre Zani <report@bugs.python.org> wrote:
> Let me know if I misunderstood Alexander, but if I didn't this should be documented with
> the datetime object. Based upon my understanding, the datetime object is a bad choice
> if you care about that ambiguity. That's not really clear.

The datetime object is neither good nor bad if you want to deal with
the DST ambiguity.  If you want to store times as local time, the best
practice is to include the UTC offset.  The datetime module now
provides the facilities to do so.  If you neglect the timezone and
deal with naive datetime objects instead, you should probably avoid
mixing it with POSIX timestamps in the same application.

Here is an example where naive datetime is quite appropriate: a
timekeeping application for a small business with a single location.
If you need to generate opening hours for a given week,
[datetime(y,m,d, 9, 0) + datetime(i) for i in range(5)] is an adequate
solution, but if you compare it to [datetime.fromtimestamp(x +
24*3600*i) for i in range(5)], you may be off by one hour if your week
spans the DST change.

In most applications, however, keeping local time without UTC offset
is a bad choice.  POSIX's timestamp only advantage is that it does no
allow keeping local time at all.