[ 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 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
hi florent! 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) behaviour! 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 easier! regards, juergen herrmann _______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de