This was entirely on my side -- I had a 'funny' in a security checker that cropped up with the tz change.
-- Garrett > -----Original Message----- > From: Gary Poster [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 19, 2005 11:37 AM > To: Garrett Smith > Cc: Zope3-Dev (email@example.com) > 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? > > Hm. > > 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? > > Gary _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com