I hacked together a fix to DateTime.py for the problems wrt. daylight saving time. I still have the impression that DateTime.py is to some degree 'broken by design' and don't know how to fix this completely without big changes to the class. Still, the attached patch should fix the problems as described in the "Z2.log and Date stamps" thread and as described in two Collector bug reports (search for "daylight" and DateTime) in a backward compatible manner. To begin with, _localzone or tz is no immutable property during the life of a Zope process (the switch to daylight saving time may happen while the Zope process is running), still DateTime uses _localzone as an immutable class attribute that's calculated only once during when the class is initialized. Furthermore, the calculation of _localzone was broken: _localzone was always set to the non-daylight saving timezone, even if we were currently in daylight saving time. Problems arose when this was mixed with the variables like hour, which were relative to the daylight saving time zone. I stick with _localzone as the non-dst zone and introduce a new, immutable class attribute _localdszone for the dst zone. Now the idea is to decide on runtime if a localtime value is non-dst or dst. I think I found and corrected the most obvious places in the class where this problem arises. I'm quite confident that with the fix, DateTime now will always return a correct date representation. Potential problems remaining to be evaluated are that DateTime *perhaps* still sometimes returns a non-dst localtime even for dates when dst was valid in your local time zone, i.e. a correct but inappropriate result. Still, that's much better than the current incorrect results. Gregor