DateTime.toZone().strftime() does not apply to returned call of toZone()
Bug #215991 reported by
Charles Choi
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
DateTime |
New
|
Low
|
Unassigned |
Bug Description
The call toZone('GMT') should return a DateTime object whose setting reflects the new time zone. However calling strftime() on the new DateTime object returns the old time value.
expires = expireDate.
Changed in zope2: | |
importance: | Undecided → Low |
affects: | zope2 → datetime |
To post a comment you must log in.
If I understand https:/ /bugs.launchpad .net/zope2/ +bug/142784 correctly, this is intended behavior.
I'm not sure *why* that's intended though; I find it highly counterintuitive.
I guess the idea was that it should work the same as python's time.strftime(), but that seems like a specious model to me, since the latter is working with struct_time inputs that carry no timezone information, so interpreting "%Z" as "local system timezone" seems reasonable for them.
I also notice that DateTime.strftime() prints nothing for the "%Z" character; maybe a clue to avoid using it :-p
IMO, a better model would have been datetime. datetime. strftime( ) which *does* respect the input's zone:
>>> import datetime datetime. now(pytz. timezone( 'US/Eastern' )) datetime. now(pytz. timezone( 'US/Pacific' ))
>>> import pytz
>>> d2 = datetime.
>>> print d2.strftime('%H:%M %Z')
18:01 EDT
>>> d3 = datetime.
>>> print d3.strftime('%H:%M %Z')
15:02 PDT
This seems much more sane than the analogous operations from DateTime:
>>> d4 = DateTime( d3).toZone( 'US/Pacific' )
>>> print d4
2008/04/25 15:02:19.079246 US/Pacific
>>> print d4.strftime('%H:%M %Z')
18:02
Are we stuck with this bizarre behavior for legacy reasons?
If so, Charles, you might have to give up and use something other than DateTime. strftime( ).
Here's one handy hack - convert to a datetime.datetime:
>>> print d4.asdatetime( ).strftime( '%H:%M %Z')
15:02 PST