On November 29, 1998 at 08:08, someone wrote:
Is there any method or proposed method for resolving conflicts like
'BST', '0300', # Brazil Standard
# 'BST', '-0100', # British Summer
I understand that I can use the TIMEZONE resource to get BST to mean
-0100, but I was wondering whether there were any proper proceedures for
making the choice that you did. (I am not challenging the choice, and can
see plenty of grounds for justifying it. I was just wondering.)
Decision was arbitrary. Date::Manip uses BST as British Summer by
default. I chose Brazil Standard since there was no other acronym for
Brazil (and plenty for Europe). However, if BST is used for British
Summer more than Brazil Standard, I have no problems switching which
is active by default. Which has greater use should be the method
for resolving conflicts for determining defaults. However, I think
no statistics are available for timezone usage, and any statistics
that may exist could be regional specific.
I'll switch BST to British Summer by default to keep consistant
with what Date::Manip chose in-case there are users familiar with
Date::Manip.
I plan to add information in the INSTALL file about timezones and at
least mention conflicting acronyms in the TIMEZONES resource page.
This way users will know to check if they need to modify TIMEZONES
to suit their locale.
Note, since MHonArc by default extracts the date of a message from
the Received fields of a message, timezone acronyms should not
come into play that often since most (decent) MTAs use hour offsets
when listing the date. Timezone acronyms will come into play more
often if the DATEFIELDS resource is changed to use the Date fields
in messages for extracting the date.
--ewh
----
Earl Hood
earlhood(_at_)usa(_dot_)net
<URL:http://www.oac.uci.edu/indiv/ehood/>
