[ python-Bugs-878424 ] Difference between two datetimes does not account for DST

[SourceForge.net]

Bugs item #878424, was opened at 2004-01-16 12:58
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878424&group_id=5470

Category: Extension Modules
>Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Kirill Lapshin (llirik)
Assigned to: Tim Peters (tim_one)
Summary: Difference between two datetimes does not account for DST

Initial Comment:
Hello,

I am having problems with using timezone aware datetime
objects across DST shift within the same timezone.

Citing documentation:

------
If both are naive, or both are aware and have the same
tzinfo  member, the tzinfo members are ignored, and the
result is a timedelta object t such that datetime2 + t
== datetime1. No time zone adjustments are done in this
case.

If both are aware and have different tzinfo members,
a-b acts as if a and b were first converted to naive
UTC datetimes first. The result is
(a.replace(tzinfo=None) - a.utcoffset()) -
(b.replace(tzinfo=None) - b.utcoffset()) except that
the implementation never overflows. 
-------

The problem is that if both datetimes have the same
tzinfo, they still may be in different "timezones" --
one in DST and the other in standard time. 

Suppose I am using US/Eastern timezone, then 4-Apr-04
is the date when DST starts. Lets create two datetimes
one (lets call it d1) for 00:00 and the other (d2) for
05:00. Now lets print the

print d1, d2, d2-d1, d2.astimezone(UTC)-d1.astimezone(UTC)

The result is 

2004-04-04 00:00:00-05:00 2004-04-04 05:00:00-04:00
5:00:00 4:00:00

Which is _very_ confusing! I think even if both
datetimes share the same tzinfo object you still have
to calculate it in "aware", not "naive" way.

Kind regards,
Kirill Lapshin

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-01-16 17:02

Message:
Logged In: YES 
user_id=31435

Since it's working as documented and as designed, this 
isn't "a bug", so I'm closing it.  You may want to reopen it as 
a feature request, but since it's arguing for an incompatible 
change in design I don't expect you'll make progress with it.

The original design of the module was debated here:

http://zope.org/Members/fdrake/DateTimeWiki/

Studying the example on the TimeZoneInfo page leaves no 
doubt that Guido intended this behavior:  if you want to mess 
with DST, fine, but then you have to convert to UTC and 
back yourself.

As the NaiveTime page says, there are (at least) three 
distinct behaviors different apps want for time arithmetic.  
Guido picked one as the default, but left it possible to get the 
others.  Of course anyone who thinks exactly one of them is 
the obvious behavior finds all the others "_very_ confusing" 
<wink>.

FWIW, I originally *implemented* datetime to work the way 
you expect.  People complained about that too.  For example, 
one early experimenter set up a 3pm weekly appointment, in 
their home time zone, and was baffled to see the hour shift 
when the week happened to cross a DST boundary (they 
expected that adding 7*24 hours would "move it a week" -- 
or, IOW, they clearly wanted naive time in this case, but 
wanted to attach a time zone anyway so they could see the 
appointment as a local time in whatever timezone they 
happened to traveling in when the appointment came due).

So one size doesn't fit all, and the default size doesn't fit you 
today.  You have to do more work, then.  I'm personally 
happy to convert to UTC by hand as needed, but it's also 
possible to define a datetime subclass and redefine 
subtraction to work the way you want it to work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=878424&group_id=5470