Hello, I'm working on changing DateTime to use pytz for timezone information. The motivation is that DateTime doesn't have up to date daylight savings time information. Rather than maintaining this stuff in DateTime it seems easier to delegate this work to a package that does this jobs better and is kept up to date. My approach is to use timezone information from pytz if it is importable, otherwise, the existing DateTime timezone information is used. I haven't made other changes to DateTime, and all existing timezones that DateTime defines are still supported (even though pytz doesn't know about some of the weird timezone names that DateTime defines.) I wanted to see if people are interested in seeing this go into Zope. One issue is that there is a daylight savings change coming up in a few weeks and so it might be nice to make these changes available to folks before then if possible. Thanks! -Amos
--On 3. Oktober 2007 15:57:59 -0400 Amos Latteier <amos@latteier.com> wrote:
Hello,
I'm working on changing DateTime to use pytz for timezone information.
The motivation is that DateTime doesn't have up to date daylight savings time information. Rather than maintaining this stuff in DateTime it seems easier to delegate this work to a package that does this jobs better and is kept up to date.
+1
My approach is to use timezone information from pytz if it is importable, otherwise, the existing DateTime timezone information is used. I haven't made other changes to DateTime, and all existing timezones that DateTime defines are still supported (even though pytz doesn't know about some of the weird timezone names that DateTime defines.)
I would not care much about dropping the support for "weird timezone names" without further notice as long as their is an easy way for people migrating their code e.g. by specifying a proper tz name.
I wanted to see if people are interested in seeing this go into Zope.
Please use a dedicated branch.
One issue is that there is a daylight savings change coming up in a few weeks and so it might be nice to make these changes available to folks before then if possible.
Possibly thoses changes won't make it into the 2.11 release so hurry up :-) -aj
On 10/4/07, Andreas Jung <lists@zopyx.com> wrote:
I would not care much about dropping the support for "weird timezone names" without further notice as long as their is an easy way for people migrating their code e.g. by specifying a proper tz name.
Lets not break too much, and instead concentrate on replacing DateTime with datetime in the long run. If this goes into 2.11, we should also get DT2dt and dt2DT in there. Being on a Grok sprint right now I don't have time to do that this week. Can I be given a deadline? I like deadlines. :-) Or somebody else can do it. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64
On Oct 4, 2007, at 5:42 AM, Lennart Regebro wrote: ...
Being on a Grok sprint right now I don't have time to do that this week. Can I be given a deadline? I like deadlines. :-)
Just to put this in perspective. People in the US will be affected again by the existing bug starting the last Sunday of this Month (Oct 28). Then, the time-zone -ffset will be off by an hour for a bout a week. It might be nice if we could get the fix in the hands of people before a new Zope release, although that may not be practical. I was thinking of releasing a separate DateTime distribution, but don't know if there would be an easy way to install it in such a way that it was ahead of the existing DateTime in the path. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote at 2007-10-4 13:37 -0400:
... It might be nice if we could get the fix in the hands of people before a new Zope release, although that may not be practical. I was thinking of releasing a separate DateTime distribution, but don't know if there would be an easy way to install it in such a way that it was ahead of the existing DateTime in the path.
Maybe, you can provide it as a (kind of hotfix) product (then you are sure, it will be imported) and use monkey patching to fix DateTime? -- Dieter
Andreas Jung wrote:
I would not care much about dropping the support for "weird timezone names" without further notice as long as their is an easy way for people migrating their code e.g. by specifying a proper tz name.
I should clarify that they are mostly abbreviations. I also agree with Lennart Regebro, that the correct solution is to replace DateTime with datetime, and so it's not worth breaking too much.
I wanted to see if people are interested in seeing this go into Zope.
Please use a dedicated branch.
Will do. Thanks! -Amos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Amos Latteier wrote:
Andreas Jung wrote:
I would not care much about dropping the support for "weird timezone names" without further notice as long as their is an easy way for people migrating their code e.g. by specifying a proper tz name.
I should clarify that they are mostly abbreviations.
I also agree with Lennart Regebro, that the correct solution is to replace DateTime with datetime, and so it's not worth breaking too much.
I think consensus here is that the DateTIme stuff has BBB contracts which are literally unbreakable: - millions of pickles are out there in ZODB land which will barf if DateTime doesn't preserve existing semantics. - Bunches of third-party application code uses the DateTime API, in particular the DWIMish constructor. I think your change (using pytz to handle timezones, with fallback to the older code) is a sensible compromise. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHBSXU+gerLs4ltQ4RAp0hAJ9YAKnuSkYGBMLG9zEK/qoLv6VMHwCfbXgJ XkIPQNsmCgRHRlmExFhMk9E= =ki/q -----END PGP SIGNATURE-----
Hi, I wanted to let folks know that I've created the amos-datetime-pytz branch with my changes. Please let me know when/if you'd like me to merge this to the trunk. Of course I'm also happy to receive any criticism or comments on the changes. Thanks! -Amos
--On 4. Oktober 2007 12:52:24 -0400 Amos Latteier <amos@latteier.com> wrote:
Hi,
I wanted to let folks know that I've created the amos-datetime-pytz branch with my changes.
Please let me know when/if you'd like me to merge this to the trunk.
Any chance getting rid of the _zlst and _zmap data cruft? Andreas
I've been working on this too today (well datetime handling anyway). Please see my patch at https://bugs.launchpad.net/zope2/+bug/149060 Laurence Amos Latteier wrote:
Hi,
I wanted to let folks know that I've created the amos-datetime-pytz branch with my changes.
Please let me know when/if you'd like me to merge this to the trunk.
Of course I'm also happy to receive any criticism or comments on the changes.
Thanks!
-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 )
I've tested my patch (datetime.datetime support) against Amos's branch and it applies cleanly and all tests pass. 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'. 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(). Ideally the old names should be mapped onto pytz timezones. Laurence Laurence Rowe wrote:
I've been working on this too today (well datetime handling anyway). Please see my patch at https://bugs.launchpad.net/zope2/+bug/149060
Laurence
Amos Latteier wrote:
Hi,
I wanted to let folks know that I've created the amos-datetime-pytz branch with my changes.
Please let me know when/if you'd like me to merge this to the trunk.
Of course I'm also happy to receive any criticism or comments on the changes.
Thanks!
-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 )
_______________________________________________ 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 )
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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
Lennart Regebro wrote:
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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?
My patch updates the existing test (substituting _millis for _micros): def testUpgradeOldInstances(self): # Compare dates that don't have the _micros attribute yet dt = DateTime('1997/1/1') dt1 = DateTime('1997/2/2') del dt._micros del dt1._micros self.testCompareOperations(dt, dt1) 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). _upgrade_old should work fine for them too as they have a time float _t attribute. def _upgrade_old(self): """Upgrades a previously pickled DateTime object.""" micros = long(math.floor(self._t * 1000000.0)) self._micros = micros return micros Laurence
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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
Lennart Regebro wrote:
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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.
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 * 1000000.0)) #self._micros = micros # don't upgrade instances in place return micros New patch at http://launchpadlibrarian.net/9811478/DateTime.patch Laurence
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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 * 1000000.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
On 10/5/07, Laurence Rowe <l@lrowe.co.uk> 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
participants (7)
-
Amos Latteier -
Andreas Jung -
Dieter Maurer -
Jim Fulton -
Laurence Rowe -
Lennart Regebro -
Tres Seaver