Re: [Zope-dev] Re: Changing DateTime to use pytz
On 10/5/07, Laurence Rowe [EMAIL PROTECTED] wrote: I've tested my patch (datetime.datetime support) against Amos's branch and it applies cleanly and all tests pass. Cool! Are there tests to make sure old pickles still work, or do we know that this is the case for sure? -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Changing DateTime to use pytz
On 10/5/07, Laurence Rowe [EMAIL PROTECTED] wrote:
It seems though that the new timezones are not used much... doing a
DateTime() gives me DateTime('2007/10/05 14:20:27.204176 GMT+1') (with
my pathc applied too). Looking up tz = d._tzinfo[d.timezone()] gives me
an old style timezone, as _tz is 'GMT+1'.
If a the timezone has a name that pytz understands then it uses pytz.
Otherwise it falls back on DateTime's timezone database. The most
common example of when pytz won't be used is with fixed offset
timezones like GMT+1. pytz.common_timezones doesn't doesn't contain
time zones like this. Anyway DateTime handles fixed offset time zones
just fine since there's no daylight savings to deal with.
It would be very useful to be able to get pytz tzinfo for a DateTime
object. It would allow me to return a timezone aware datetime.datetime
from asdatetime().
DateTime instances only store the name of their timezone, not the
timezone object. So when converting to a datetime object I suggest
that you generate a tzinfo object yourself. This shouldn't be too hard
since DateTime is willing to give you a timezone that provides a name,
dst flag, and offset from UTC. See _timezone.info()
Ideally the old names should be mapped onto pytz timezones.
Names that pytz understands use pytz time zone info, regardless of
when the DateTime instance was created. Or maybe you are asking
something else.
Also DateTime supports some abbreviations. For example, 'est' is
mapped to 'US/Eastern'. So old instances that use 'est' as a time zone
should work with pytz. There are probably improvements that can be
made here, but I didn't bother since my goal was to change as little
as possible.
-Amos
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Changing DateTime to use pytz
On 10/5/07, Laurence Rowe [EMAIL PROTECTED] wrote: If anyone thinks it is important I could an explicit upgrade path for instances with a _millis attribute too (most current instances I would assume). I think the code must work with current instances without modifying them. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Changing DateTime to use pytz
On 10/5/07, Laurence Rowe [EMAIL PROTECTED] wrote: All the tests still pass if I comment out the assignment: def _upgrade_old(self): Upgrades a previously pickled DateTime object. micros = long(math.floor(self._t * 100.0)) #self._micros = micros # don't upgrade instances in place return micros That seems like a reasonable solution. (Although maybe _upgrade_old isn't the best method name then, but that's details ;) ), -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
