On Fri, Jun 4, 2010 at 15:17, Alexander Belopolsky
<report@bugs.python.org> wrote:
>
> Alexander Belopolsky <belopolsky@users.sourceforge.net> added the comment:
>
> 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.

Great!

>
>> 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.

Well, I think the time module needs to be slowly phased out in
preference for datetime and we stop monkey-patching the time tuple
over and over again. The datetime module provides a much nicer
interface and TOOWTDI, but that's a long term goal.

>
> 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.

True.

>
> 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.

Or #3: We have a UTC class as originally proposed way back when. We
can even make all the methods staticmethods so that I get my desire to
not require instantiating an instance while you do get your
pseudo-singleton you originally wanted.

>
>> 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.

Sure, but we are not even there yet to consider that use case are we?

>
>> ..
>> 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).

Yes, I was typing from the cuff.

>  Is the surprise
> you have in mind that PDT.utcoffset(dt) is the same for dt in June and
> January?

Exactly.

> 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.

This is all starting to feel like the entire tzinfo ABC needs to be
re-thought and either expanded upon or replaced.

>
> 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.

This is why I hate datetime stuff. =)

>
>> 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.

So how about this: we implement a UTC class now which contains only
staticmethods to get you your singleton and me not having to
instantiate the class. Then you take your time in possibly expanding
the tzinfo class or coming up with a new ABC which replaces tzinfo
that fixes all of these crazy problems. I have been arguing from a
code maintainability and naive user POV, you from an experienced
datetime POV. Lets solve my POV now and just start the ball rolling in
solving your POV properly long-term instead of trying to shoe-horn
known issues into pre-existing stuff. People complain about datetime
enough, so let's take the time to fix it. The UTC class can be a
stop-gap until datetime gets fixed (which could be in 3.2 if stuff
happened really rapidly and the UTC solution can be ripped out; it's
just code).