> > IMHO, the best approach would be to make mxDateTime available separately
> > from DateTime in the _ variable. That would avoid breaking any code, but
> > allow anyone who wanted to use mxDateTime that option from within Zope.
> >
> > I think a product that adds mxDateTime to the _ variable would be your
> > best bet.
> Well, my opinion, too. On the long run this might get the preferred way of
> dealing with time stuff so that the use of DateTime gets depreceated. But
> I guess DC needs to decide this.. I also dunno if there are any problems
> with mxDateTime being used (e.g. security concerns, whatever) as
> I havent't
> looked to closely at this.

Note the "DC needs to decide..." only applies to what we
decide to integrate (and thus sign up to maintain, at some
level) into the core. One of the key goals of our long-term
strategy of becoming much more component-oriented is that
the "marketplace" (aka the community) decides what the best
component is for a given task.

And we do not have to wait for the full component story to
land for this to happen; as noted, I'm sure someone could
come up with a product that "componentizes" mxDateTime in
some way so that people who prefer it can use it easily.

Time and de facto usage would then tell whether we (DC) should
consider some sort of transition - and we can learn whether
that would be a good idea without inconveniencing those who
prefer to continue using the built-in DateTime in the meantime.

Brian Lloyd        [EMAIL PROTECTED]
Software Engineer  540.371.6909
Digital Creations  http://www.digicool.com

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to