[ Florent Guillaume wrote:]
> 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
>> 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.
actually that's the best thing to do! this way the implementer knows
what to do exactly :)
but be aware that some tests got modified to pass with current (broken)
one more question (to the public!):
do we REALLY need dates <1900 / >2036 ? using unix timestamps for
storage and as the base for all conversions would make things a lot
regards, juergen herrmann
>> XLhost.de - eXperts in Linux hosting <<
Bruderwöhrdstraße 15b, DE-93051 Regensburg
Fon: +49 (0)700 XLHOSTDE [0700 95467833]
Fax: +49 (0)721 151 463027
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -