cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: curl_getdate and timezones

From: Christopher R. Palmer <crpalmer_at_vivisimo.com>
Date: Mon, 08 Aug 2005 16:22:06 -0400

> 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?

Daniel Stenberg wrote:
> 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?

The date parser is actually very nice to have (I was trying to borrow it
for other purposes). Unfortunately for me, I do really need the timezone
parsing because dates are written with timezone abbreviations far too
frequently.

On the other hand, I can see why you wouldn't really want to support the
hacky list of timezones (are they ever used by any correct web server?).

Leaving the parsing broken doesn't sound like a good idea to me. If you
want, I can send you a patch that will fix the existing list of timezone names?

Cheers,
Chris.
Received on 2005-08-08