[Python-Dev] Issue 2736: datetimes and Unix timestamps (original) (raw)
Guido van Rossum guido at python.org
Mon Jun 4 20:52:07 CEST 2012
- Previous message: [Python-Dev] Issue 2736: datetimes and Unix timestamps
- Next message: [Python-Dev] Issue 2736: datetimes and Unix timestamps
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.belopolsky at gmail.com> wrote:
On Mon, Jun 4, 2012 at 1:12 PM, Guido van Rossum <guido at 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)
- Previous message: [Python-Dev] Issue 2736: datetimes and Unix timestamps
- Next message: [Python-Dev] Issue 2736: datetimes and Unix timestamps
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]