A piece of code calls bobobase_modification_time() which currently
returns a DateTime; after that the piece of code calls some
DateTime-specific methods on the returned object. Now in Zope 2.12 we
make bobobase_modification_time() return a datetime.datetime and
subsequently the piece of code
Philipp von Weitershausen wrote:
I think we need Zope to use some frankendatetime (a datetime.datetime
that also supports the old DateTime API) throughout the deprecation
period. Whenever people make a call to the old DateTime API on a
frankendatetime object, they'll get a deprecation warning
Andrew Milton wrote:
-1 for any scheme that deliberately breaks currently working code / installs.
It's pretty broken already ;)
-1 for any scheme that involves diddling the ZODB to 'fix' pickles, because
you just know you're going to corrupt someone's ZODB, and that's just
noone's
Philipp von Weitershausen wrote:
Chris suggests. Why does it need to be persistent?
See the use case I sketched out in my other reply...
1. Create some extensive tests about how DateTime currently works. I'm
currently working on this to see whether any further procedure makes sense.
yay!
Lennart Regebro wrote:
Just a note: I don't think mixing in persistance is needed.
Hmm... how so? I've always thought it quite nice that when, for example,
you store the modification time of an object in a DateTime, you can
safely update it without worrying about the whole object having to
Chris Withers wrote:
Philipp von Weitershausen wrote:
I think we need Zope to use some frankendatetime (a datetime.datetime
that also supports the old DateTime API) throughout the deprecation
period. Whenever people make a call to the old DateTime API on a
frankendatetime object, they'll
On 11/29/05, Chris Withers [EMAIL PROTECTED] wrote:
Hmm... how so? I've always thought it quite nice that when, for example,
you store the modification time of an object in a DateTime, you can
safely update it without worrying about the whole object having to be
repickled when you change it...
On 11/29/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
We could deprecate DateTime now to warn people about that. But then
their product would only either work with Zope 2.12 or with Zope 2.12
(depending on whether it still expects the DateTime API or the
datetime.datetime API); it
[ Lennart Regebro wrote:]
On 11/29/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
We could deprecate DateTime now to warn people about that. But then
their product would only either work with Zope 2.12 or with Zope 2.12
(depending on whether it still expects the DateTime API or the
Lennart Regebro wrote:
I agree, official deprecation and warnings should only happen when we
have a real backwards compatibility and transition-path. Which would
include what you call a frankendatetime. :-)
Which, as I understand it, is what Jürgen Herrman wanted to create...
Not if I
Andreas Jung wrote:
I agree that is should be replaced but I also mentioned that we tried to
achieve that already some years ago and we gave upso talking about
deprecation really makes sense when someone puts a replacement module on
the table. I know that the DateTime module is a piece
Chris Withers wrote:
Andreas Jung wrote:
I agree that is should be replaced but I also mentioned that we tried
to achieve that already some years ago and we gave upso talking
about deprecation really makes sense when someone puts a replacement
module on the table. I know that the
+---[ Philipp von Weitershausen ]--
| 2. If we find it's possible, we rid the current DateTime implementation
| and recreate the DateTime class by subclassing datetime.datetime. For
| backwards compatability, we make sure that old pickles can be revived
| and that the old
Andrew Milton wrote:
+---[ Philipp von Weitershausen ]--
| 2. If we find it's possible, we rid the current DateTime implementation
| and recreate the DateTime class by subclassing datetime.datetime. For
| backwards compatability, we make sure that old pickles can be
On 11/28/05, Philipp von Weitershausen [EMAIL PROTECTED] wrote:
Datetimes are dull values, they should just pickle nicely.
They do. A module with extra utilities + timezone support would be nice.
1. Create some extensive tests about how DateTime currently works. I'm
currently working on this
Lennart Regebro wrote:
Datetimes are dull values, they should just pickle nicely.
They do.
Yes, that's my point. That's why we don't need added persistency.
A module with extra utilities + timezone support would be nice.
pytz provides some extensive timezone support. Not sure what the extra
Peter Bengtsson wrote:
-1 on making DateTime deprecated. I'm sure thousands of zope people
use DateTime in thousands of places. Technically it might be correct
deprecate it but politically it's just going to put people off from
upgrading.
I'm sure it would be fairly trivial to write an
Lennart Regebro wrote:
It depends on what you mena with deprecated. It *is* deprecated from
the point of view, that if you start developing something new now,
then don't use it.
Really? What should we be using instead then?
It is not deprecated in the way that this will go away in the
On 11/25/05, Chris Withers [EMAIL PROTECTED] wrote:
Really? What should we be using instead then?
datetime works much better in most cases.
I honestly think it _should_ go away, just with plenty of notice...
Well, possibly.
--
Lennart Regebro, Nuxeo http://www.nuxeo.com/
CPS Content
If I have a vote, +1 on deprecation and replacement with something less
buggy. We have spent enormous amounts of time trying to sort out and then
work around DateTime problems. On the other hand, we have a substantial
amount of code that uses DateTime and finally, mostlyt works. We'd be
--On 25. November 2005 12:22:05 -0800 Dennis Allison
[EMAIL PROTECTED] wrote:
If I have a vote, +1 on deprecation and replacement with something less
buggy.
You can only deprecate when you have something better. As long as there is
no useful replacemenet there is nothing to deprecate
True. But the context of this thread was whether deprecation made sense
or not. I was agreeing with Chris that the DateTime problems are better
solved by replacement than by patching, but also that there is a large
amount of code that has been made to work using the current DataTime and
--On 25. November 2005 12:43:48 -0800 Dennis Allison
[EMAIL PROTECTED] wrote:
True. But the context of this thread was whether deprecation made sense
or not. I was agreeing with Chris that the DateTime problems are better
solved by replacement than by patching, but also that there is a
On 11/23/05, Chris Withers [EMAIL PROTECTED] wrote:
Hi Jürgen,
Many thanks for even thinking about looking at the DateTime debacle ;)
Jürgen Herrmann wrote:
Well, that would be cool. Just a question: How do you plan to keep and
verify backwards compatibility? Any database, with any type of
On 11/24/05, Peter Bengtsson [EMAIL PROTECTED] wrote:
-1 on making DateTime deprecated. I'm sure thousands of zope people
use DateTime in thousands of places. Technically it might be correct
deprecate it but politically it's just going to put people off from
upgrading.
It depends on what you
Hi Jürgen,
Many thanks for even thinking about looking at the DateTime debacle ;)
Jürgen Herrmann wrote:
Well, that would be cool. Just a question: How do you plan to keep and
verify backwards compatibility? Any database, with any type of
DateTime object, must work transparently.
100%
Jürgen Herrmann wrote at 2005-11-21 10:33 +0100:
... difficult to understand timezone handling ...
once again sry, if i raised expectations on the fix of strftime.
I am a bit astonished that you need to understand timezone handling
in order to implement an improved DateTime.strftime.
The only
On 11/21/05, Jürgen Herrmann [EMAIL PROTECTED] wrote:
recently i came up here with the intention to fix DateTime#strftime().
while trying this, i had to dig deeper and deeper into the implementation
of DateTime and especially the timezone and daylight saving stuff.
to be honest, it's
--On 21. November 2005 15:14:50 +0100 Lennart Regebro [EMAIL PROTECTED]
wrote:
Well, that would be cool. Just a question: How do you plan to keep and
verify backwards compatibility? Any database, with any type of
DateTime object, must work transparently.
Perfect question. When we considered
[ Andreas Jung wrote:]
--On 21. November 2005 15:14:50 +0100 Lennart Regebro [EMAIL PROTECTED]
wrote:
Well, that would be cool. Just a question: How do you plan to keep and
verify backwards compatibility? Any database, with any type of
DateTime object, must work transparently.
Perfect
[ Lennart Regebro wrote:]
On 11/21/05, Jürgen Herrmann [EMAIL PROTECTED] wrote:
recently i came up here with the intention to fix DateTime#strftime().
while trying this, i had to dig deeper and deeper into the
implementation
of DateTime and especially the timezone and daylight saving stuff.
On 11/21/05, Andreas Jung [EMAIL PROTECTED] wrote:
--On 21. November 2005 15:14:50 +0100 Lennart Regebro [EMAIL PROTECTED]
wrote:
Well, that would be cool. Just a question: How do you plan to keep and
verify backwards compatibility? Any database, with any type of
DateTime object, must
--On 21. November 2005 15:37:42 +0100 Jürgen Herrmann
[EMAIL PROTECTED] wrote:
btw. you mentioned mxDateTime - is it recommendable to make it a
requirement for zope or should we better stick to python's datetime?
Python's datetime module would be the way to go. In 2001/2002 mx.DateTime
33 matches
Mail list logo
