Agreed that having a robust tzinfo object representing "local time, whatever it is" would be a good feature too. This shouldn't have to depend on the Olson tz database; it should just consult the libc localtime function.
--Guido On Mon, Jun 4, 2012 at 11:30 AM, Alexander Belopolsky <alexander.belopol...@gmail.com> wrote: > On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum <gu...@python.org> wrote: >> A big +1 on making conversions between POSIX timestamps and datetime >> (with or without timezone) easier. > > I am all for achieving this goal, but I think the root of the problem > is not the lack of mxDT's ticks() method. Note that someone who > requires robust behavior across the DST change would still be puzzled > about what to supply as arguments to the .ticks(offset=0.0,dst=-1) > method. > > I think the key feature that is missing from datetime is the ability > to obtain local time complete with timezone offset. See issue 9527. > Once we have that, adding .ticks() that requires a timezone aware > datetime instance will complete the puzzle. > > The problem with adding .ticks() to naive datetime instances is the > inherent ambiguity in what such instances represent. mxDT resolves > this by offering offset and dst arguments, but this is just moving the > problem from one place to another without solving it. -- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
