DecodeTimeZone() in synautil.pas has 2 problems:
Example for chained ELSE IF instead of unbound IFs:
if s = 'NZDT' then x := 13 else
if s = 'IDLE' then x := 12 else
if s = 'NZST' then x := 12 else
Wrong timezone entries (with current values commented out in curly brackets) and what they should be:
if s = 'GST' then x := {10} -2 else
if s = 'CCT' then {x := 8} begin zone:= 6* 30+ 30; result:= TRUE; exit; end else
if s = 'WAST' then x := {7} 2 else
//if s = 'SST' then x := 2 else
if s = 'WAT' then x := {-1} 1 else
if s = 'BST' then x := {-1} 1 else
if s = 'CAT' then x := {-10} 2 else
if s = 'EAST' then x := {-10} 6 else
if s = 'NT' then {x := -11} begin zone:= -3* 30- 30; result:= TRUE; exit; end else
Timezone SST should be removed, as it can be both "Samoa Standard Time" or "Singapore Standard Time" and the differ drastically. Timezones CCT and NT give back the correct non-full hour offset and must exit the function immediately to not execute the later code that multiplies x by 60. Many more timezone abbreviations exist that could be added - I could provide them upon request (or in general a more efficient way to check).
It is minor problem, because major purpose is decode timestamp from the emails. Old RFC822 allows just some abbrevations. And newer RFC2822 does not allow any abbrevation.
I will not to duplicate special libraries like TZDB.
I must think about it...
I never used this function anyway, so I couldn't care less. But argumenting with what an RFC allows just disregards what servers could (and do) send - it's about being able to understand others even when it's not legal as per RFC (but still unambiguous enough). Just like GetMonthNumber() does (although inefficiently again). That's why my own function supports 215 timezone abbreviations - because it's possible.