[Python-checkins] python/nondist/sandbox/datetime US.py,1.4,1.5

2002年12月25日 17:17:57 -0800

Update of /cvsroot/python/python/nondist/sandbox/datetime
In directory sc8-pr-cvs1:/tmp/cvs-serv28846
Modified Files:
	US.py 
Log Message:
Explained that the "unrepresentable hour" at the end of DST can't be
avoided by choosing to call 01:HH:MM standard time instead of daylight
time. *Which* hour becomes unrepresentable changes then, but not that
*some* hour is unrepresentable.
Index: US.py
===================================================================
RCS file: /cvsroot/python/python/nondist/sandbox/datetime/US.py,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -d -r1.4 -r1.5
*** US.py	25 Dec 2002 23:53:45 -0000	1.4
--- US.py	26 Dec 2002 01:17:55 -0000	1.5
***************
*** 16,30 ****
 # range(1:00:00, 2:00:00) on that day *intends* to refer to standard
 # or daylight time, and adding a tzinfo object modeling both DST and
! # standard time doesn't improve that. We arbitrarily decide it intends
! # DST then. A consequence is that there's no way to spell a time in
! # the 1-hour span starting when DST ends: 2:HH:MM on that day is
! # taken as being in standard time, while 1:HH:MM is taken as DST, and
! # in UTC there's a one-hour gap between 1:59:59 and 2:00:00.
 #
 # On the other end, when DST starts at 2am on the first Sunday in April,
 # the naive clock magically jumps from 1:59:59 to 3:00:00. A naive time
 # of 2:HH:MM on that day doesn't make sense. We arbitrarily decide it
! # intends DST then, making it a redundant spelling of 1:HH:MM in standard
! # time on that day.
 
 dstoff = timedelta(hours=1)
--- 16,46 ----
 # range(1:00:00, 2:00:00) on that day *intends* to refer to standard
 # or daylight time, and adding a tzinfo object modeling both DST and
! # standard time doesn't improve that.
! #
! # DST 1am 2am 3am ...
! # standard 1am 2am ...
! #
! # There isn't a good solution to deciding what 1:MM:HH means then. If
! # you say it's DST, then there's no way to spell a time in the 1-hour
! # span starting when DST ends: 1:HH:MM would be taken as DST, 2:HH:MM
! # as standard, and in UTC there's a one-hour gap between 1:59:59 DST
! # and 2:00:00 standard. The UTC times in that gap can't be named.
! #
! # OTOH, if you say 1:MM:HH is standard time then, there's no way to
! # spell the hour preceding 1:00:00:. 12:59:59 must be taken as DST,
! # and by hypothesis 1:00:00 is taken as standard, and again there's a
! # one-hour gap between those in UTC.
! #
! # The implementation can't win, so this one arbitrarily decides to call
! # 1:MM:HH DST (I expect that's what most people would expect). A
! # consequence of the "missing hour" (under either choice) is that
! # UTC -> this timezone -> UTC can't always be an identity (some one-hour
! # range of UTC times simply can't be spelled in this timezone).
 #
 # On the other end, when DST starts at 2am on the first Sunday in April,
 # the naive clock magically jumps from 1:59:59 to 3:00:00. A naive time
 # of 2:HH:MM on that day doesn't make sense. We arbitrarily decide it
! # intends DST then, making it a redundant spelling of 1:HH:MM standard
! # on that day.
 
 dstoff = timedelta(hours=1)
***************
*** 77,81 ****
 if convert_endpoints_to_utc:
 start -= self.stdoff # start is in std time
! end -= (self.stdoff + self.dstoff) # end is in DST time
 
 # Can't compare naive to aware objects, so strip the timezone from
--- 93,97 ----
 if convert_endpoints_to_utc:
 start -= self.stdoff # start is in std time
! end -= self.stdoff + self.dstoff # end is in DST time
 
 # Can't compare naive to aware objects, so strip the timezone from