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 brian@digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com