On Fri, Jun 4, 2010 at 4:09 PM, Brett Cannon <report@bugs.python.org> wrote:
..
> For the allowable range, follow the datetime docs as someone might be relying on that specification already.
>
Will do.  I think it is as simple simple s/12/24/ in two places of the
current patch, but I will check and make sure it is tested by
unittests.

> As for the ongoing DST debate, it seems we either need to say that since we cannot properly support all possible
> datetimes properly we should simply not even try, fixed offset or not, or we provide a class that gives the proper UTC
> offset, but in no way adjusts itself as people might expect or want. I'm arguing for the former, Alexander wants the latter.
>

I disagree with your premise that "we cannot properly support all
possible datetimes." If issue1647654 patch is applied, I can rewrite
datetimeex.py so that print(localtime()) is consistent with the system
date utility on Linux/MacOS/BSD for all times.  This however can be
achieved without DST offset in timezone object.

The only issue is what time.strftime("%Z", localtime().timetuple())
will print.  Recall that tm_isdst (the last entry in timetuple) is set
according to what dst() returns.  If dst() is None,  tm_isdst = -1, if
dst() is timedelta(0),  tm_isdst = 0 and if dst() is non-zero
timedelta, tm_isdst = 1.  In these three cases, %Z will be formated as
empty string, time.tzname[0] ('EST' in New York) and time.tzname[1]
('EDT' in New York) respectively.

I would really like to get localtime() in datetime library at the next
step. In the distant future, datetime.now() can be redefined to return
aware local time.  If this happens, we need to decide what
localtime().dst() should return.  With the current patch, it will
return timedelta(0) which is wrong 50% of the time.  A correct
alternative is to return None, but this will be rather odd for
timezone.utc.

It appears that in order to implement dst() correctly to the letter of
tzinfo specification there are really two choices:

1.  Have separate classes: UTC and FixedOffsetTimezone with different
dst().  UTC().dst(dt) -> timedelta(0) and
FixedOffsetTimezone(offset).dst(dt) -> None.

2. Have a single class with dst(dt) returning fixed stored value.

I think #2 clearly wins on simplicity.

> I still stand by my argument that it is not needed for the two use cases that we concretely have in the stdlib for a
> timezone class: a UTC instance and %z directive in strptime.

I agree.  The third member is needed to support aware local time,
which is the third use case.

> ..
> I can still see a naive user thinking that DST is the same around the world and being taken
> by surprise when thing don't adjust accordingly by the timezone when he does ``timezone("PDT", 7, dst=True)``.

The actual syntax would be PDT = timezone(timedelta(hours=7), "PDT",
dst=timedelta(hours=1)) (or -1 - I have to check).  Is the surprise
you have in mind that PDT.utcoffset(dt) is the same for dt in June and
January? I agree this is not ideal and I would much rather not allow
timezone.utcoffset() to take an argument, but this is not possible
within the tzinfo design.  Best we can do is to make the argument to
utcoffset() optional and naive users will not even know that they can
pass time value to the timezone methods.

I think this is still less evil than to have an aware datetime t with
t.tzname() -> 'PDT' and time.strftime('%Z', t.timetuple()) -> 'PST'.

> Plus giving people any semblance of a DST-supporting timezone class is just going to lead for more calls of the
> stdlib to include concrete timezone instances that do manage DST.
>

Again, managing DST is to use different timezone instances for
different real times.  It is not hard to do that.  Implementing
time-dependent utcoffset(dt) in a concrete tzinfo subclass is
impossible unambiguously.  In the long term we should be looking to
deprecate the time argument to tzinfo methods.

> Unless other people step forward to debate this we probably are not going to reach consensus
> without going to python-dev to see what others think.

Given the history of such discussions, I think we should reach
consensus here first.  I don't mind starting with a two-component
timezone class and dst() returning None for all instances including
timezone.utc.  I still believe the cost of supporting DST is really
small and adding it now is easier than in the future.