This was entirely on my side -- I had a 'funny' in a security checker that
cropped up with the tz change.
> -----Original Message-----
> From: Gary Poster [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 19, 2005 11:37 AM
> To: Garrett Smith
> Cc: Zope3-Dev (firstname.lastname@example.org)
> Subject: Re: [Zope3-dev]
> zope.security.interfaces.ForbiddenAttribute: ('utcoffset', <UTC>)
> On Jul 18, 2005, at 7:04 PM, Garrett Smith wrote:
> > This might be something on my end, but I figure I'd throw it out in
> > case it's related to any changes related to naïve/non-naïve time
> > zones.
> > Here's the relevant part of the traceback:
> > File "/opt/aktari/zope/src/zope/i18n/format.py", line
> 175, in format
> > info = buildDateTimeInfo(obj, self.calendar, bin_pattern)
> > File "/opt/aktari/zope/src/zope/i18n/format.py", line 603, in
> > buildDateTimeInfo
> > tz_secs = tzinfo.utcoffset(dt).seconds
> > I'll dig further, but at a casual glance I couldn't turn up any
> > security declarations for UTC objects. Could this be a case where
> > datetime values are suddenly spouting proxied tzinfos?
> security proxies, of course, can't be persisted, so this
> would only happen if your datetime were proxied (which is
> completely reasonable).
> Did you try just making a security declaration and seeing if
> that fixed the issue? I haven't encountered the problem. I
> would think you could just do something like
> <class class="pytz.UTC">
> <allow interface="zope.interface.common.idatetime.ITZInfo" /> </class>
> I'm not sure where to put this in zope.app...maybe zope.app.interface?
Zope3-dev mailing list