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 would
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
[ 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
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)
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
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, t
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 be
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!
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 idea
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 tel
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 e
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 t
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
+---[ 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 D
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 tha
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 of
--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
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
that
--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 :
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
unhappy
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 M
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
future
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 unpgrade
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
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
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% compati
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 o
--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
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 obje
[ 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 savi
[ 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.
>
--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 considere
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 comp
hi all!
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 completely hacked together :(
DateTimeZone.py has one BIG d
34 matches
Mail list logo