First I'll answer your question 3. Having defined timezone does not mean it will work.
---------------------------------------- #include <stdio.h> #include <time.h> int main() { tzset(); printf("%ld\n", timezone); printf("%ld\n", _timezone); return 0; } ---------------------------------------- $ gcc -Wall test.c test.c: In function `main': test.c:7: warning: long int format, pointer arg (arg 2) $ ./a 4198632 -28800 ---------------------------------------- Enough? (Not well tested, uh?) Second, no one should ignore backward compatibility (M$'s success is partly owing to this, as well as Unix's popularity), as long as it does not violate the design rules (standards-conformance, etc.). I don't think, say, respecting the second argument of gettimeofday is a sin; those not wanting it can simply pass NULL. There is a SERIOUS misunderstanding about standards conformance here. An unusable timezone is a violation, but well-behaved ftime and gettimeofday are NOT. Just as the morale of network protocol implementation is: Be generous to accept, and be prudent to send. So I think in programming we also should make environments (run-times, librabries) as compatible as possible, and write applications as portable as possible. A standard should specify what we SHOULD do, but it never restricts what we COULD do. Not to mention that what I asked for has long been there in the UNIX tradition already. As I have said already, "unspecified" in a standard means the standard does not say anything about the implementation, and, IMHO, the implementors are free to choose from the best practices. Better practices mean better compatibility, don't they? Summary of my points. Making ftime and gettimeofday get timezone information is not a violation of any standards, and will make Cygwin only better (unless someone thinks better compatibility is a sin). Hope I am clear enough. I am arguing here for a BETTER Cygwin. Best regards, Wu Yongwei --- Original Message from Karsten Fleischer --- > 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/