On Thu, 4 Aug 2005, Christopher R. Palmer wrote:

> Looking at the parsedate.c code in curl 7.14.0 I notice that it has a table
> of timezone offsets and that these offsets seem to define the daylight and
> non-daylight savings times as the same offset from GMT. For example:
>
> {"PST", 480}, /* Pacific Standard */
> {"PDT", 480}, /* Pacific Daylight */
>
> Is that intentional? Do you remember why it is done like that?

The information used for that table was taken from the original getdate.y
code. But when I look at it now, I see that I overlooked the fact that the
"*DT" time zone names (and a few others) are listed as tDAYZONE as opposed to
the rest that are tZONE.

So, this is a flaw introduced by me when I rewrote the date parser!

See the getdate.y file as it looked like before we deleted it from the curl
CVS repo:

http://cool.haxx.se/cvs.cgi/curl/lib/Attic/getdate.y?rev=1.27&content-type=text/vnd.viewcvs-markup

> This is not the behaviour of the GNU date command which returns different
> times for different daylight/non-daylight timezones:

This whole business with trying to detect time zones by name is really not a
good idea anyway - as the are numerous "official" time zones sharing the same
name. Not to mention how daylight savings time is next to impossible to track
and adapt to globally.

I think we are better off either 1) do nothing and remain doing it wrong like
now or 2) cut the support for these time zone names.

Or would this cause us/you/someone grief?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html