Re: [Oorexx-devel] Platform timezone information.

[<rvj...@xs...>]

according to the manpage tzset(void) is fine on MacOSX, as is =20
tzsetwall(void)

time.h contains

struct tm {
	int	tm_sec;		/* seconds after the minute [0-60] */
	int	tm_min;		/* minutes after the hour [0-59] */
	int	tm_hour;	/* hours since midnight [0-23] */
	int	tm_mday;	/* day of the month [1-31] */
	int	tm_mon;		/* months since January [0-11] */
	int	tm_year;	/* years since 1900 */
	int	tm_wday;	/* days since Sunday [0-6] */
	int	tm_yday;	/* days since January 1 [0-365] */
	int	tm_isdst;	/* Daylight Savings Time flag */
	long	tm_gmtoff;	/* offset from CUT in seconds */
	char	*tm_zone;	/* timezone abbreviation */
};

so that also must be fine.

Ren=E9.
On 14 jan 2008, at 15:27, Rick McGuire wrote:

> I've been looking into the challenge of adding some timezone support =20=

> to Date()/Time().  Most of the pieces are in place to easily =20
> implement this, but the difficult part might be retrieving the =20
> timestamp information from the different systems.
>
> On Windows, we're currently using the GetLocalTime() function, which =20=

> does not return any timezone information about the broken down =20
> timestamp value other than a daylight savings time indicator.  A =20
> second call will be required to retrieve the timezone information, =20
> then apply either the daylight savings bia or the standard time bias =20=

> based on the flag setting in the system time structure.
>
> On the unix systems, there's an extension to the tm structure that =20
> includes a tm_gmtoff field (or depending on the platform, a =20
> __tm_gmtoff) field.  I'm concerned about the portability of that =20
> field.   The current code is using the tm struct value returned by =20
> the localtime() (or localtime_r() function on AIX).  That offset =20
> value would be ideal, if available.  I'm a little concerned about =20
> using tzset(), which depends on external variables, after the =20
> problem with accessing the external variable on the Mac for the =20
> environment.  Is tm_gmtoff field a reliable field on the different =20
> unix systems (and which name should be used).  As an absolute =20
> fallback, I can take the timestamp, convert to both local and system =20=

> time and compute the bia myself....but that's a real pain.
>
> Rick
> =
-------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> =
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketpla=
ce_______________________________________________
> Oorexx-devel mailing list
> Oor...@li...
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel