I'm running Zope 2.7.4 and I'm trying to format the current time in the format "yyyymmddhhmmssZ" (that is with a timezone of UTC), but I can't do it. The DateTime API says that "A DateTime object's methods return values based on the timezone context." This appares to be the case for all except strftime(). For example (my local timezone is US/Eastern): now = DateTime('US/Pacific') now.pCommonZ() Jan. 30, 2005 12:35 am US/Pacific now.rfc822() Sun, 30 Jan 2005 00:35:58 -0800 now.strftime('%Y/%m/%d %H:%M:%S %Z') 2005/01/30 03:35:58 EST It looks like Collector Bug 1127 (http://zope.org/Collectors/Zope/1127/) changed strftime() to always work in the local timezone, instead of always working in GMT as it did before. But shouldn't it respect the timezone of the DateTime object as do the other methods? Is this a bug? -- Ron
Ron Bickers wrote at 2005-1-30 03:47 -0500:
I'm running Zope 2.7.4 and I'm trying to format the current time in the format "yyyymmddhhmmssZ" (that is with a timezone of UTC), but I can't do it.
The DateTime API says that "A DateTime object's methods return values based on the timezone context." This appares to be the case for all except strftime(). ... now.rfc822() Sun, 30 Jan 2005 00:35:58 -0800
now.strftime('%Y/%m/%d %H:%M:%S %Z') 2005/01/30 03:35:58 EST
It looks like Collector Bug 1127 (http://zope.org/Collectors/Zope/1127/) changed strftime() to always work in the local timezone, instead of always working in GMT as it did before. But shouldn't it respect the timezone of the DateTime object as do the other methods? Is this a bug?
I yesterday looked at the implementation of "DateTime.strftime" (Zope 2.7.2). Apparently, it tries to take the timezone into account. And it works for me:
now=DateTime() now DateTime('2005/01/30 19:32:08.823 GMT+1') now.strftime('%H') '19'
-- Dieter
On Sunday 30 January 2005 01:33 pm, Dieter Maurer wrote:
I yesterday looked at the implementation of "DateTime.strftime" (Zope 2.7.2). Apparently, it tries to take the timezone into account.
And it works for me:
now=DateTime() now
DateTime('2005/01/30 19:32:08.823 GMT+1')
now.strftime('%H')
'19'
What do you get when you try my examples? You only used your local timezone, which works fine for me too, but it doesn't work when I'm trying to use a different timezone than my own. Also, according to notes in the bug I referenced, it looks like the behavior may have changed starting with 2.7.4. -- Ron -- Ron Bickers Logic Etc, Inc.
On Sunday 30 January 2005 03:47 am, Ron Bickers wrote:
I'm running Zope 2.7.4 and I'm trying to format the current time in the format "yyyymmddhhmmssZ" (that is with a timezone of UTC), but I can't do it.
The DateTime API says that "A DateTime object's methods return values based on the timezone context." This appares to be the case for all except strftime().
Ok. Looking into time.strftime(), I can see the difficulty in making this work as expected, but I found a way to get what I want. Don't know why I didn't think of it before. utc = DateTime('UTC') "%4d%02d%02d%02d%02d%02dZ" % utc.parts()[:6] Not as pretty, but it works. I guess one can always roll their own strftime with string formatting and all the other DateTime methods. If strftime() is always going to return the time in the local timezone, I suggest it be documented in the API since it's inconsistent with the other methods. Thanks! -- Ron
--On Montag, 31. Januar 2005 1:38 Uhr -0500 Ron Bickers <rbickers-list-zope2@logicetc.com> wrote:
On Sunday 30 January 2005 03:47 am, Ron Bickers wrote:
I'm running Zope 2.7.4 and I'm trying to format the current time in the format "yyyymmddhhmmssZ" (that is with a timezone of UTC), but I can't do it.
The DateTime API says that "A DateTime object's methods return values based on the timezone context." This appares to be the case for all except strftime().
Ok. Looking into time.strftime(), I can see the difficulty in making this work as expected, but I found a way to get what I want. Don't know why I didn't think of it before.
utc = DateTime('UTC') "%4d%02d%02d%02d%02d%02dZ" % utc.parts()[:6]
Not as pretty, but it works. I guess one can always roll their own strftime with string formatting and all the other DateTime methods.
If strftime() is always going to return the time in the local timezone, I suggest it be documented in the API since it's inconsistent with the other methods.
If you think that this is a bug: file a collector issue preferred with a patch and unittests if you want to see this fixed in the next releases. Andreas
participants (3)
-
Andreas Jung -
Dieter Maurer -
Ron Bickers