parsetm.c /c/cygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/sdk/bin/ar m-wince-link -NOLOGO -DEBUG -DEBUGTYPE:CV -INCREMENTAL:NO -PDB:parsetm.pdb /c/c ygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/lib/plc4.lib / c/cygwin/home/user/hg/mozilla-central/objdir-wm6-test/xulrunner/dist/lib/nspr4.l ib ws2.lib coredll.lib -DLL -OUT:parsetm.dll parsetm.obj Creating library parsetm.lib and object parsetm.exp parsetm.obj : error LNK2019: unresolved external symbol _tzset referenced in fun ction nspr_test_runme parsetm.obj : error LNK2019: unresolved external symbol _putenv_s referenced in function nspr_test_runme parsetm.dll : fatal error LNK1120: 2 unresolved externals make: *** [parsetm.dll] Error 96
I commented out _putenv_s and _tzset and run this test anyway but I got strange result: BEGIN TEST parsetm rv = 0 Fri Mar 8 20:13:52 UTC 1912 rv = 0 Fri Mar 8 20:13:52 UTC 1912 parsetm Passed END TEST parsetm Is this another issue?
(In reply to comment #1) > BEGIN TEST parsetm > > rv = 0 > Fri Mar 8 20:13:52 UTC 1912 > rv = 0 > Fri Mar 8 20:13:52 UTC 1912 > parsetm Passed > > END TEST parsetm > > Is this another issue? This was year 2038 problem.
PRTime is a 64-bit timestamp, so it is not affected by the year 2038 problem, and it should take care when using 32-bit time_t to avoid the year 2038 problem. So the strange output you showed in comment 1 should be an NSPR bug. To fix the build error, you can change #if _MSC_VER >= 1400 to #if _MSC_VER >= 1400 && !defined(WINCE)
(In reply to comment #3) > PRTime is a 64-bit timestamp, so it is not affected by the > year 2038 problem, and it should take care when using 32-bit > time_t to avoid the year 2038 problem. I know. But I suspect this invoking mktime causes the problem. http://mxr.mozilla.org/nspr/source/nsprpub/pr/src/misc/prtime.c#1632 > So the strange output you showed in comment 1 should be an > NSPR bug. OK. I will file a new bug entry. > To fix the build error, you can change > #if _MSC_VER >= 1400 > to > #if _MSC_VER >= 1400 && !defined(WINCE) I've already changed so.
I post the diff anyway.
Assignee: wtc → ikezoe
Status: NEW → ASSIGNED
Attachment #376791 - Flags: review?(wtc)
Comment on attachment 376791 [details] [diff] [review] A patch But we have code that is supposed to handle the case when mktime() returns (time_t) -1: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/nsprpub/pr/src/misc/prtime.c&rev=3.42&mark=1632,1634,1645-1652#1632 Could you find out why the code is not working? I checked in your patch on the NSPR trunk (NSPR 4.8). Checking in parsetm.c; /cvsroot/mozilla/nsprpub/pr/tests/parsetm.c,v <-- parsetm.c new revision: 1.2; previous revision: 1.1 done
(In reply to comment #6) > (From update of attachment 376791 [details] [diff] [review]) > But we have code that is supposed to handle the case when > mktime() returns (time_t) -1: Unfortunately on WinCE, mktime does not return -1 in some cases. Before invoking mktime(&localTime) localTime.tm_year is 139 (i.e. 2039), but after invoking the function, localTime.tm_year is 2 and returns value (secs) is -2117514496.
I opened bug 492450.
Thanks. Then we can mark this bug fixed.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.