[Python-Dev] TZ-aware local time

[R. David Murray]

On Mon, 11 Jun 2012 10:01:57 -0700, Guido van Rossum <guido at python.org> wrote:
> On Mon, Jun 11, 2012 at 6:33 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
> > On Fri, Jun 8, 2012 at 11:06 PM, Guido van Rossum <guido at python.org> wrote:
> >> On Fri, Jun 8, 2012 at 2:08 PM, Alexander Belopolsky
> >> <alexander.belopolsky at gmail.com> wrote:
> > ..
> >>>>>> t = mktime((2010, 11, 7, 1, 0, 0, -1, -1, 0))
> >>>>>> for i in range(5):
> >>> ... Â  Â  print(strftime("%T%z", localtime(t + i - 2)))
> >>> ...
> >>> 01:59:58-0400
> >>> 01:59:59-0400
> >>> 01:00:00-0500
> >>> 01:00:01-0500
> >>> 01:00:02-0500
> >>>
> >>> As I explained at <http://bugs.python.org/msg109452>, it is not
> >>> possible to reproduce this sequence using LocalTimezone.
> >>
> >> So LocalTimezone (or any named timezone that uses DST) should not be
> >> used for this purpose.
> > ..
> >> I'm still unsure what problem you're trying to solve.
> >
> > The problem is: produce a timestamp (e.g. Â RFC 3339) complete with
> > timezone information corresponding to the current time or any other
> > unambiguously defined time. Â This is exactly what my proposed
> > datetime.localtime() function does.
> 
> Maybe the problem here is the *input*? It should be a POSIX timestamp,
> not a datetime object.
> 
> Another approach might be to tweak the existing timetuple() API to
> properly compute the is_dst flag? It currently always seems to return
> -1 for that flag.
> 
> >> Can we just
> >> introduce LocalTimezone (or whatever name it should have) and let the
> >> issue rest?
> >
> > No. Â LocalTimezone adresses a different problem and does not solve
> > this one. Â If you generate a timestamp using
> > datetime.now(LocalTimezone).strftime("... %z"), your timestamps will
> > be wrong for one hour every year. Â Some users may tolerate this, but
> > the problem is not hard to solve and I think datetime module should
> > offer one obvious and correct way to do it.
> 
> Ok, I trust that LocalTimezone doesn't solve your problem. Separately,
> then, I still think we should have it in the stdlib, since it probably
> covers the most use cases besides the utc we already have.
> 
> PS. TBH I don't care for the idea that we should try to hide the time
> module and consider it a low-level implementation detail for the shiny
> high-level datetime module. The simply serve different purposes. Users
> should be required to understand POSIX timestamps and the importance
> of UTC before they try to work with multiple timezones. And they
> should store timestamps as POSIX timestamps, not as datetime objects
> with an (implicit or explicit) UTC timezone.

For the email package, I need a way to get from 'now' to an RFC 5322
date/time string, and whatever that way is it needs to (1) be unambiguous
what time in what timzeone offset it is when the user passes it to me,
and (2) it needs to interoperate with date/time+timezone-offset that is
obtained from other email headers.  An aware timezone using a 'timezone'
tzinfo object seems the most logical thing to use for that, which means
I need a way to go from 'now' to such a datetime object.

I don't care how it happens :)

--David