none
time function RRS feed

  • Question

  • Hi, I'm new to C++ and I am writing a project in it that I want to build on both Windows CE and VxWorks, so I am compiling the project in both MS Visual Studio and Wind River Workbench. 

    There are a number of places in the app where I want to get the current date and time (number of seconds since 1/1/1970) but I can't figure out how to make it work!  From what I can tell, time(time_t * timer) is the way to go, but while this compiles fine for VxWorks, when I compile it for Windows I get a strange linker error which says that there are unresolved externals in the function that contains the call to time().

    Help! (Thanks in advance!)

    Rachel

    Wednesday, July 5, 2006 7:49 PM

Answers

  • Apparently, the old time functions arent implemented in the runtime library for Windows CE. You could resort to Win32 methods like GetLocalTime and GetTimeZoneInformation instead for your Visual Studio build.

    Wednesday, July 5, 2006 9:02 PM

All replies

  • All you do is include time.h, and do something similar to the following snippet?

    time_t x;
    time(&x);

    Wednesday, July 5, 2006 7:55 PM
  • That's exactly what I want to do--here is essentially what I'm doing:

    #include "time.h"

    void foo(void)
    {
        time_t curr_time;
        time(&curr_time);
    }

    or I was wondering if this was an option:

    void foo(void)
    {
        time_t curr_time = time(NULL);
    }

    Either way I get the same error:

    error LNK2019: unresolved external symbol time referenced in function "protected: void __cdecl foo(void)"

    It seems like it should be simple, what is going on???

    Wednesday, July 5, 2006 8:09 PM
  • The preprocessor plays games with time_t and time().  They get redefined to __time64_t and _time64().  What exactly are the undefined symbols you get?

    Also make sure the the project property Linker, Input, Ignore all default libraries is set to No.

    Wednesday, July 5, 2006 8:14 PM
  • The property setting is as you suggested, and as for the undefined symbol, do you mean unresolved symbol?  All the error message says is "unresolved external symbol time...".  (Is there some way to get more information about the error that you're wanting to know?)  The problem is with the function call, because I can declare the time_t variables without a problem, it is only when I add the function call that I get the failure. 

    (Thanks for you help, I'm really tearing my hair out over this)

    Wednesday, July 5, 2006 8:32 PM
  • There is no time() function in the CRT, just _time32 and _time64.  Is there any chance that you're using Wind River's time.h header file instead of Microsoft's?  In case of doubt, set the /showIncludes compile option.

    Wednesday, July 5, 2006 8:41 PM
  • Using _time64 allowed the project to compile in VS, but will not compile in WB with this call.  I wish MS was more POSIX-compliant!  Do you know of any options for me that will work for both?  Otherwise I can try defining a macro that will be defined differently depending on the platform, but this would not be ideal.
    Wednesday, July 5, 2006 9:01 PM
  • Apparently, the old time functions arent implemented in the runtime library for Windows CE. You could resort to Win32 methods like GetLocalTime and GetTimeZoneInformation instead for your Visual Studio build.

    Wednesday, July 5, 2006 9:02 PM
  • As an alternative, you could use the Dinkumware time implementation in both builds.
    Wednesday, July 5, 2006 9:05 PM
  • VS2005 is POSIX compliant as long has you use their header file.  They are just trying to make sure that the Y2K038 problem won't hurt you.  Hey, it is only 32 year away.  I'll be retired by then though...

    Anyhoo, please explain why you have to include Wind River's time.h instead of MSFT's.

    Wednesday, July 5, 2006 9:13 PM
  • I am using the VS2005 time.h header file.  But if it is POSIX-compliant, why won't it recognize structs like "timespec" and functions like "clock_gettime" which are part of the POSIX API?
    Wednesday, July 5, 2006 9:38 PM
  • Oops, don't get cranky with me.  I just said that it implements the POSIX function time().  They obviously chose not to implement clock_gettime().  I don't know why but that is not the point.  If you include MSFT's version of time.h, you should not get an undefined, oops, unresolved symbol when you link.  Use /showIncludes and post the output and we'll help you out.

    Wednesday, July 5, 2006 10:07 PM
  •  nobugz wrote:
    Oops, don't get cranky with me.  I just said that it implements the POSIX function time().  They obviously chose not to implement clock_gettime().  I don't know why but that is not the point.  If you include MSFT's version of time.h, you should not get an undefined, oops, unresolved symbol when you link.  Use /showIncludes and post the output and we'll help you out.

    As I've pointed out, the time method isn't implemented in the runtime library for Windows CE.

    Wednesday, July 5, 2006 10:10 PM
  • I wasn't trying to be rude at all, I was just asking--I do appreciate your help.  What is MSFT?  The time.h I am using is the one provided for Windows Mobile, since I am using CE.  So, this version is undoubtedly different from the full framework version and perhaps that is the discrepency here, as einaros notes time() is not implemented in this version.  Because as I understand, this time.h provides _time64() which will not work in VxWorks and the VxWorks time.h provides time() and clock_gettime() which will not work in CE. 

    I will look into this Dinkumware suggestion by einaros as well. 

    Thursday, July 6, 2006 2:09 PM
  • I'm not sure it's completely clear for readers of this thread what the conclusive answer to this problem is. I have looked into it and ran into a thread where (someone claiming to be) a member of the CE team explained that time.h does indeed contain definitions of POSIX like time-functions, but they are not implemented anywhere, so anyone attempting to link with them will get a linker error.

    I found the following implementation of time_t time(time_t *t) based on the time functions that do exist on CE. I haven't verified the code myself, but at a glance it looks sound enough. Just place this snippet in your code and Robert's your fathers brother.

    time_t time( time_t *inTT )
    {
    SYSTEMTIME sysTimeStruct;
    FILETIME fTime;
    ULARGE_INTEGER int64time;
    time_t locTT = 0;

    if ( inTT == NULL ) {
    inTT = &locTT;
    }

    GetSystemTime( &sysTimeStruct );
    if ( SystemTimeToFileTime( &sysTimeStruct, &fTime ) ) {
    memcpy( &int64time, &fTime, sizeof( FILETIME ) );
    /* Subtract the value for 1970-01-01 00:00 (UTC) */
    int64time.QuadPart -= 0x19db1ded53e8000;
    /* Convert to seconds. */
    int64time.QuadPart /= 10000000;
    *inTT = (time_t)int64time.QuadPart;
    }
    return *inTT;
    }
    Thursday, November 30, 2006 8:04 AM
  • This seems pretty broken. If anyone at MS is listening they should consider either making the time.h header emit a "warning, POSIX time(time_t *) not implemented, use 64 bit version" message or better yet, why not just make time_t a 64 bit typedef? Isn't that why time uses time_t and not say, int? This stinks of Y2K knee-jerkerey to me.

     

    I wonder how many developer YEARS have been cumulatively lost re-discovering the solution to this issue?

     

    I just used the 64 bit versions and that also "just works".

     

    CV

    Tuesday, December 26, 2006 9:12 PM
  • Avery Simonsen, locTT variable would be static!
    Tuesday, November 14, 2017 1:10 PM