darcs patch: Figure out timezone offset from timezone name

[David Leuschner]

>> David and I have discussed this, and it seems like this hard-coded
>> timezone database is in any case better than the current incorrect
>> behavior. In the majority of cases it will do the right thing, instead
>> of being almost always incorrect as it is now. I have pushed the patch
>> now, but there are some improvements that could be made:
>
> I think this is wrong. Time-zones change quite frequently, and now any 
> program compiled with 'time' will be incorrect the next time some 
> government changes its zone.

Which time zone is used at what time indeed changes frequently but I am
not aware of any case where the meaning of a time zone _name_ changed.
CEST always refers to +0200 although the periods during which this time
zone is used changes. The patch doesn't try to figure out which time zone
should be used for a certain place at a certain time. It only maps the
names that are typically used to refer to time zones to their time offset.

> Is there an alternative approach? Is there some way we can query the tz 
> database? I looked into this earlier but didn't find an obvious way.

Querying the time zone database doesn't help in this case.  It only
provides information which time zone was (or should be) used at a certain
place at a certain time.  This patch changes only the way time zone names
including a time zone name are parsed.  

Ambiguity really is a problem (and for that reason it would be best to not
use time zone names at all). Quoting from a mail to Björn:

> Ambiguity of names really is a problem because PST can refer to "Pacific
> Standard Time" which is -07:00 as well as "Pakistan Standard Time" which
> is +05:00.  But even here detailed time zone information doesn't provide
> any help as the meaning doesn't depend on where the computer doing the
> decoding is located but where the formatted timestamp originated
> from. (And in which context it appeared. For example RFC822 clearly
> indicates that PST should mean -07:00).  To accomodate for this all
> parsing functions should probably return lists of valid interpretations
> but that would break the library interface.
> 
> At the moment the library doesn't even indicate, that it could not
> interpret the time zone and silently returns nonsense like
> 
> TimeZone 0 False "CEST"
> 
> which is just wrong because "CEST" has an offset of 120 minutes.

As a final note PostgreSQL has excellent time and time zone handling and
uses exactly this approach.  They deal with ambiguity by allowing the
database administrator to use localised mapping tables, see

http://www.postgresql.org/docs/8.1/static/datetime-keywords.html

Cheers,

   David

-- 
David Leuschner
Meisenweg 7
79211 Denzlingen
Tel. 07666/912466