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:
Lennart Regebro wrote:
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?
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 =
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
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
Lennart Regebro wrote:
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
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
-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
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