Mail Archives: cygwin/2002/03/25/18:03:59
> Thank you for your suggestions. The points are:
>
> 1) Cygwin did very well, but not now;
That's irrelevant, Cygwin's behavior is SUSv2 compliant, AFAICS.
> 2) I was not using ftime to get time, but to get timezone information.
OK, another quote from the SUSv3 docs
http://www.opengroup.org/onlinepubs/007904975/functions/ftime.html:
--->>
FUTURE DIRECTIONS
This function may be withdrawn in a future version.
<<---
[This wasn't in the SUSv2 docs, though.]
So, _do not_ use this function to get time or timezone information.
> 3) timezone variable is not usable in Cygwin.
Why not?
In my installation 1.3.10 installation I see this in the <time.h> header
file:
--->>
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
<<---
And _timezone is declared some lines above:
--->>
extern __IMPORT time_t _timezone;
<<---
This is not strictly following the SUSv2 or SUSv3 standards, but it
should work.
SUSv2 says:
--->>
The following are declared as variables:
extern int daylight;
extern long int timezone;
extern char *tzname[];
<<---
SUSv3 says:
--->>
The following shall be declared as variables:
extern int daylight;
extern long timezone;
extern char *tzname[];
<<---
timezone is a macro on Cygwin, but the typecast is OK.
You can dig through the Cygwin sources and send in a patch to make
Cygwin fully SUS compliant.
> So timezone is now not portable. Cygwin broke some "unportable" code.
It didn't talk about "unportable" code.
What I was trying to say is, that you wrote code that doesn't follow the
standards and that is likely to break on any other platform.
Read the SUSv2 at the link that Christopher Faylor gave you already.
SUSv3 is quite new, so it's likely that other platforms are not really
compliant to this new standard, yet.
Karsten
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -