Menu
▾
▴
#1550 timezone is missing from time.h
closed-fixed
2011-05-23
2011-05-23
No
My version of ming32 is mingw32-runtime-3.15.2.
% cat > time.c << EOF
heredoc> #include <time.h>
heredoc> #include <stdio.h>
heredoc>
heredoc> int main(void)
heredoc> {
heredoc> printf("timezone=%i\n", timezone);
heredoc> return 0;
heredoc> }
heredoc> EOF
% /usr/bin/i686-pc-mingw32-gcc -std=c99 time.c -o time
time.c: In function 'main':
time.c:6:26: error: 'timezone' undeclared (first use in this function)
time.c:6:26: note: each undeclared identifier is reported only once for each function it appears in
I already reported this on:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3295430&group_id=2435
But it was wrongly closed, and due to this"
https://sourceforge.net/tracker/?func=detail&aid=3306236&group_id=2435&atid=102435
I could not reopen, nor reply.
The issue is not that timezone is not defined, it is not defined with strict ansi (i.e. -std=c99). I will work on a fix.
The issue is that timezone is undefined.
When, how, and why, is something to investigate *in* the bug report.
You should not close bug reports as invalid without any investigation, specially without giving the opportunity to reply.
Providing details as to when, how and why you ran in to the issue would greatly help identify the issue (as you did in your second report). I simply do not have time to try every permutation of gcc option to see when the error might occur. Based on your original report your statement was timezone was undefined, I did investigate and sure enough it was defined, it just so happened that it was not defined in the scenario you mentioned.
As to closing the report, that is SourceForge's default behaviour now. My lesson learned from this is to override the default behaviour and allow for additional comment.
Had I know the details, I would have provided the details. If you don't have time to try every permutation, do you think I have it? I just saw it failing on my software, which was working before.
You should have said "Works fine here", then I would have checked, as I did, and _then_ I found out it only happens with -std=c99.
Fair enough, I will choose my values when responding to a report more carefully going forward. If possible, should you encounter an issue in the future, if you could provide a simple test case (as your time permits) or if you could provide your compile and / or link lines (as appropriate) it will help greatly with determining the source of the issue.
Thank you.
Yea, well I would have probably closed the original post as Invalid as well and primarily because you didn't give enough information but I would have executed a grep command for timezone in time.h first and said the same as Chris. See http://www.mingw.org/Reporting_Bugs for more on reporting issues.
The real problem exists that timezone isn't provided by MS. You'll need to use _get_tzname as described http://msdn.microsoft.com/en-us/library/4ssfs1ya.aspx or use strftime as described http://msdn.microsoft.com/en-us/library/fe06s4ak\(v=vs.80).aspx.
Perhaps Chris can add an implementation of timezone but we need to find the definition defined by C99 first. Is there one?
How is it then that it links and runs fine?
I'm doing this workaround on my app:
+#ifdef __MINGW32__
+__MINGW_IMPORT long timezone;
+#endif
I've reworked the guards in time.h to expose timezone, daylight and tzname when compiling with __STRICT__ANSI__. I've committed the fix and it will be included in the next release.