[Python-checkins] python/dist/src/Misc NEWS,1.617,1.618

[tim_one@users.sourceforge.net]

Update of /cvsroot/python/python/dist/src/Misc
In directory sc8-pr-cvs1:/tmp/cvs-serv2341/python/Misc

Modified Files:
	NEWS 
Log Message:
"Premature" doc changes, for new astimezone() rules, and the new
tzinfo.fromutc() method.  The C code doesn't implement any of this
yet (well, not the C code on the machine I'm using now), nor does
the test suite reflect it.  The Python datetime.py implementation and
test suite in the sandbox do match these doc changes.  The C
implementation probably won't catch up before Thursday (Wednesday is
a scheduled "black hole" day this week <0.4 wink>).


Index: NEWS
===================================================================
RCS file: /cvsroot/python/python/dist/src/Misc/NEWS,v
retrieving revision 1.617
retrieving revision 1.618
diff -C2 -d -r1.617 -r1.618
*** NEWS	18 Jan 2003 23:22:19 -0000	1.617
--- NEWS	22 Jan 2003 04:45:50 -0000	1.618
***************
*** 46,50 ****
    irritation most likely seen on Windows systems.
  
!   In dt.asdatetime(tz), if tz.utcoffset(dt) returns a duration,
    ValueError is raised if tz.dst(dt) returns None (2.3a1 treated it
    as 0 instead, but a tzinfo subclass wishing to participate in
--- 46,50 ----
    irritation most likely seen on Windows systems.
  
!   In dt.astimezone(tz), if tz.utcoffset(dt) returns a duration,
    ValueError is raised if tz.dst(dt) returns None (2.3a1 treated it
    as 0 instead, but a tzinfo subclass wishing to participate in
***************
*** 61,69 ****
    by a later example coded by Guido.
  
!   datetimetz.astimezone(tz) no longer raises an exception when the
    input datetime has no UTC equivalent in tz.  For typical "hybrid" time
    zones (a single tzinfo subclass modeling both standard and daylight
    time), this case can arise one hour per year, at the hour daylight time
!   ends.  See new docs for details.
  
    The constructors building a datetime from a timestamp could raise
--- 61,85 ----
    by a later example coded by Guido.
  
!   datetime.astimezone(tz) no longer raises an exception when the
    input datetime has no UTC equivalent in tz.  For typical "hybrid" time
    zones (a single tzinfo subclass modeling both standard and daylight
    time), this case can arise one hour per year, at the hour daylight time
!   ends.  See new docs for details.  In short, the new behavior mimics
!   the local wall clock's behavior of repeating an hour in local time.
! 
!   dt.astimezone() can no longer be used to convert between naive and aware
!   datetime objects.  If you merely want to attach, or remove, a tzinfo
!   object, without any conversion of date and time members, use
!   dt.replace(tzinfo=whatever) instead, where "whatever" is None or a
!   tzinfo subclass instance.
! 
!   A new method tzinfo.fromutc(dt) can be overridden in tzinfo subclasses
!   to give complete control over how a UTC time is to be converted to
!   a local time.  The default astimezone() implementation calls fromutc()
!   as its last step, so a tzinfo subclass can affect that too by overriding
!   fromutc().  It's expected that the default fromutc() implementation will
!   be suitable as-is for "almost all" time zone subclasses, but the
!   creativity of political time zone fiddling appears unbounded -- fromutc()
!   allows the highly motivated to emulate any scheme expressible in Python.
  
    The constructors building a datetime from a timestamp could raise