Hi there - I and a colleague have been working with Zope on WinNT with MySQL/ODBC as the database, with generally very good success. Zope is awesome! However, in one particular situation we noted the following strange behavior - MySQL select queries were mysteriously failing with a parse error in RDB.py, related to not being able to parse a DATETIME field. After looking at DateTime.py and concluding that DateTime should be able to parse virtually anything ;-), we were initially very puzzled as to the cause of the parse error. However, after eliminating everything else we could think of, we finally found that it was the fact that NT was returning the value 'Tokyo Standard Time' as the timezone for our machine - a value which is not listed in the _zmap in DateTime - so, DateTime was failing here: # Current time, exp in specified timezone t,tz=time(),self._tzinfo._zmap[lower(arg)] We added the mapping 'tokyo standard time':'Tokyo' to _zmap, restarted Zope, and now everything's working fine. However, when I looked into implementing the same fix on my Japanese NT Server machine, I found that python's time.tzname gives me back 'PST' even though my machine is set for Japan's time zone :-( . A suggestion: Would it be better to get the numerical time zone via time.timezone and then convert it to some set string for each time zone, rather than rely on time.tzname? Incidently, with the Solaris installation of Zope I have, Japan's time zone is given as 'JST', which would also require an entry in DateTime to avoid an error similar to the above. _zmap is useful for parsing date strings, but should it be used to determine the time zone when a more sure method is available? Thoughts, anyone? --Brian