I think that, while on one side is very comfortable to recycle others code, there
should have been a very good reason for DC to develop that class. I had the impression
that the class is heavily used in the internals of Zope, and probably the integration
of an external module would mean a major redesign issue. Always in my opinion, in the
long run automaintained code can be easier to leverage and adapt. In the end, if the
original developer does not support the code anymore or change it in a way that is not
possible to upgrade, DC will have major problems.
The idea of developing an internal class is, for me, a good point. However, I think
that DC did not approached the international subject simply because, as far as I
understood, Zope was build on the American market. While they should be terribly proud
of the magnificent product thay have done, in future they will be facing more and more
the problem of other countries using it.
This is why I am looking to fix the DateTime class starting from their code. This
problem will occur also for the formatting of values, for instance. As far as I have
seen, when you ask Zope to return a number formatted as currency, you get it in
dollars, with the "." and "," used where central europeans put them the other way
I do not know if DC or somebody else is already approaching this issue, and I admit
that I have looked around but I haven't found anything about this, but I am pretty
sure that the european developers like me and you which are trying to find a RAD for
the internet, will find Zope as one of the best products, and the spread of it will
sooner or later raise more and more problems on this side.
I was asking this on the ml because I am considering proposing a project on this, but
I wanted to be sure that this was not already been done somewhere else
IMHO the long term solution would be to use the mxDateTime 
module instead of the DateTime module that currently uses Zope.
> I am playing around with the DateTime module in order to adapt it to other formats
>than the American one. However, I would like not to start a work that someone is
>already doing or that is already done. I have found a little patch that solves
>temporarily the problem, but I would like to do something more definitive.
> However, I need to be careful due to the large use that is done internally by Zope.
>To whom can I get in touch regarding this issue?
> Best regards
> Stefano Vedovelli
> Zope-Dev maillist - [EMAIL PROTECTED]
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -