I recommend mentioning your philosphy with respect to your proposed
changes. Possible philosophies could be:
1) We support the mininum number of timezones required
by RFC 822 by default.
2) We support a subset of popular timezones, in order
to cover many common cases, by default.
3) We support all timezones listed in official
standard X by default.
a) We are extensible in full hour increments.
b) We are extenisible in minute increments
c) We extensibly deal with acronym name sapce collisions
d) We extensibly deal with the historical changes of
timezones; i.e. mail sent from Libya in 1913 will be time zone
corrected differently than mail sent from Libya in 1953
Quite frankly, getting it "right" requires a huge historical lookup
table, timezone offsets to the second, and other nightmares. The
governemnt timezone documents I was looking at (referenced from
http://www.bsdi.com/date) really were mind numbingly complex and
required constant revision.
I personally think philosphy 2a is quite adequate. I suspect nobody
would ever take advantage of philosphy 2b, (which appears to be what
you are suggesting) but have no fundamental opposition. For what it's
worth, I was getting maybe 3 emails out of 1000 with an unrecognized
timezone offset, and they were almost invariably MET and AEST. I think
the more obscure the timezone, the more likely we would get a
numerical offset in the email.
Jeff
