R: [Zope-dev] Playing with DateTime

[Stefano]

Hello

well, my idea was, as I said, to create a pubblic interface called DateTi=
me,
and then wrap mxDateTime or other forms behind it. This will make it full=
y
compatible with the existing DC implementation. Then if soembody like me
needs a more flexible implementation, as in my case a class that accepts =
and
returns things in the central european format, then he/she can decide
whatever or not use this implementation.

Best regards
Stefano

-----Messaggio originale-----
Da: Brian Lloyd [mailto:brian@digicool.com]
Inviato: venerd=EC 16 marzo 2001 20.09
A: Christian Scholz; Casey Duncan
Cc: spinwing@inwind.it; zope-dev@zope.org
Oggetto: RE: [Zope-dev] Playing with DateTime


> > IMHO, the best approach would be to make mxDateTime available separat=
ely
> > from DateTime in the _ variable. That would avoid breaking any code, =
but
> > allow anyone who wanted to use mxDateTime that option from within Zop=
e.
> >
> > I think a product that adds mxDateTime to the _ variable would be you=
r
> > 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. B=
ut
> I guess DC needs to decide this.. I also dunno if there are any problem=
s
> 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