Actually, the problem I'm talking about is specific to timezomes > UTC +1200. The code that parsed the date headers was under the assumption that +1200 was the max timezone and so anything greater than that was treated as rubbish.
After the first report of this problem, I did some digging and found that the code was wrong, and that +1400 was the max timezone offset. I just don't remember when this was fixed, so I don't know if it made it into 1.4.5 or is still in CVS waiting to be released as 1.4.6 (which will hopefully be released soonish, after we resolve an important thread/fork issue for a customer on rh7.3 where forking causes all threads to exit). Jeff On Sun, 2003-12-14 at 09:44, Enver ALTIN wrote: > On Sun, 2003-12-14 at 16:36, Jeffrey Stedfast wrote: > > this problem has already been fixed (will be available in 1.4.6 if it > > isn't already in 1.4.5) > > I think the fix already went in for 1.4.5, since I've been using it for > a while now and it seems to calculate time fields correctly in my local > time and takes care of local daytime saving changes automagically. > > -HTH _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
