From simon.urbanek at r-project.org  Thu Jan 20 03:33:56 2005
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Thu Jan 20 03:34:17 2005
Subject: [Rd] Re: [R-SIG-Mac] Formatting of time zone for POSIXct
In-Reply-To: <Pine.LNX.4.61.0501192213270.22189@gannet.stats>
References: <p06110407be1445a3fc3f@[128.115.153.6]>
	<A8792BF6-6A64-11D9-BC92-000D93AE1C66@math.uni-augsburg.de>
	<Pine.LNX.4.61.0501192213270.22189@gannet.stats>
Message-ID: <BB8D4DBC-6A8B-11D9-8644-000A959F327E@r-project.org>

On Jan 19, 2005, at 5:39 PM, Prof Brian Ripley wrote:

> There is _no_ tm_tzone component in a POSIX nor C99 tm structure (and 
> I have just checked both), so if a system requires it to be set, the 
> bug is not in R but in the standards-compliance of the system.

> I am happy to zero the structure, much less happy to reference 
> undocumented non-POSIX/C99 components.

I'm completely happy with zeroing the structure as is seems to fix this 
standards-compliance problem for multiple platforms without the need to 
check for specific headers and behaviors. The only reason I attached 
the second solution was that I was perplexed why someone would use the 
complicated #ifdefs just to initialize a field to zero, so I thought 
there may be more to it...

AFAICS tm_zone and tm_gmoff are BSD extensions and obviously made it to 
GNU as well. Being extensions implies that a structure must be zeroed 
out before use, otherwise the implementation has no way of knowing 
whether the trailing values (wrt standard) are valid or not. If the 
various standards don't mention zeroing structures before use, then 
this may be interpreted as breaking POSIX/C99 standard, but 
nevertheless it still makes sense. Since it does no harm on POSIX 
platforms (just being redundant) and supports arbitrary extensions, I 
think we should go for it... just my two pennies ..

Cheers,
Simon


[Rd] Re: [R-SIG-Mac] Formatting of time zone for POSIXct
Simon Urbanek