Jürgen Herrmann 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 completely hacked together :(
DateTimeZone.py has one BIG dictionary in it, not a single line of
comments. values of this dict are nested lists, among other hackish
things (list like usage of a string, with \000 as separator).
the methods that use this dict also have no comments/docstrings at all.
obviously the guy(s) that originally wrote this, is/are hiding (i know
why :) so, there's nobody to ask either...

sorry guys, i won't be able to completely fix this for now. i found
a way to monkey patch zope to make it work for my case (2 timezones
only). my plan is to completely reimplement DateTime, based on
python's datetime in my own freetime (maybe around xmas this year)
and give it back to the community.

once again sry, if i raised expectations on the fix of strftime.

Yes replacing DateTime is a laudable but difficult goal.

One thing that could be done meanwhile is just refactor the unit test to be a base class that could then be used to test DateTime or to test another potential implementation. That would go a long way to help actually write a new implementation.


Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to