Alexander Belopolsky <alexander.belopol...@gmail.com> added the comment:
On Mon, Jun 4, 2012 at 3:21 PM, Alexandre Zani <rep...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14908> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
