curl-library
Re: curl_getdate and timezones
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