I think there might be a slight issue with timezone bias calculation. In this function (haven't checked but similar could be used somewhere else too):
function TimeZoneBias : String; in OverbyteIcsSmtpProt.pas if timezone could not be calculated (TIME_ZONE_ID_INVALID) or if it is GMT (UTC) it returns -0000 as result. But here is what RFC 2822 says: --- The form "+0000" SHOULD be used to indicate a time zone at Universal Time. Though "-0000" also indicates Universal Time, it is used to indicate that the time was generated on a system that may be in a local time zone other than Universal Time and therefore indicates that the date-time contains no information about the local time zone. ---- Notice the capitalized "SHOULD" in RFC. So in other words "-0000" means that this timezone info is meaningless. "+0000" would mean - this date was generated on a client that is in UTC timezone e.g. London. But "-0000" could be for example used by server to add or correct invalid timezone but if the server is in different timezone than sender of the original email it might mean the above - it fixed the date but the timezone is no longer relevant to the original sender so cannot be used to determine where the original message time zone is. So if this is all correct - my suggestion for modification if this is all right would be to: - return -0000 if TIME_ZONE_ID_INVALID - return +0000 if timezone is UTC or GMT etc - for any use by clients - return -0000 - for any use by servers Also a question - is there a function to return TDateTime version of RFC-formatted date in Mimeparser? I could not find it... or am I supposed to do my own parser for RFC date from headers because the result from mime parser is raw RFC formatted date? -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
