mktime () is broken in ANSI Library

[McGregorMortis]

You're kidding me!

What good is a standard if fully-compliant implementations can't work together because of stuff like this?

Grumble grumble.

[cdk52]

A more serious issue is that time_t values as determined by CVI at the same instant in different parts of the world are in general _different_. The value is meant to be the number of seconds elapsed since epoch at the Greenwich meridian (UTC, formerly known as GMT).

Today, as a test, I called CVI's ansi_c library function time() three times on my PC (in Melbourne, Australia), changing time zones between the calls.

Here are my results. Note that "Change" is relative to the first value:

Location :: Time Zone :: Returned :: (decimal) :: Change

Melbourne :: UTC + 10h :: 0xC6096696 :: 3322504854 :: 0
Perth :: UTC + 8h :: 0xC6094AE5 :: 3322497765 :: -7089
Melbourne :: UTC + 10h :: 0xC609672A :: 3322505002 :: 148

If your app needs to communicate across time zones, this can create real problems.

I now used Windows SDK functions to handle time.

(Overall, I think that CVI is a great product :))

Regards,
Colin.

[Alex D]

I performed a similar test in both VC2003 and CVI 7.1 and had no problems. Can you give me some details on exactly what you did to produce these results?

Thanks,

Alex

[cdk52]

Responding to Alex D.

I ran the folowing code in the Interactive execution window four times, changing time zones between runs. The changes in local time shown are purely the result of the time zone changes (i.e. I did not adjust the clock at all).

/*******************************************************/
#include < utility.h >
#include < ansi_c.h >

static time_t calTime;

time (&calTime);
DebugPrintf ("Current calendar time is 0x%x\n", calTime);
/*******************************************************/

Here are the results:
1. Timezone set to Melbourne, Australia (UTC + 10h)
Ran interactive statements (Shift-F5) at 07:54 18 Apr 2005 local
Debug output:
Current calendar time is 0xc60d5979

2. Timezone set to Perth, Australia (UTC + 8h)
Ran interactive statements (Shift-F5) at 05:55 18 Apr 2005 local
Debug output:
Current calendar time is 0xc60d3d95

3. Timezone set to London, UK (UTC + 0h)
Note: UK is currently on daylight saving time.
Ran interactive statements (Shift-F5) at 22:56 17 Apr 2005 local
Debug output:
Current calendar time is 0xc60ccd50

4. Timezone set to Melbourne, Australia (UTC + 10h)
Ran interactive statements (Shift-F5) at 07:58 18 Apr 2005 local
Debug output:
Current calendar time is 0xc60d5a68

As you can see, the calendar time changes according to the time zone, which is wrong. It should increase with each call, by about 60 or 120 seconds.

Regards,
Colin.

[Alex D]

I have still not been able to reproduce this behavior. What version of CVI are you using? What version of windows? Also, I assume you are changing the time zone in the windows control panel; if you are doing something different, let me know.

Thanks,

Alex

[Wendy L]

Hello all,

Along with Alex D, I am unable to reproduce the problem you are seeing when you change your timezones. I am using CVI 7.1 and Windows XP SP1, and I see the correct behavior. What is your system setup?

Thanks.

[cdk52]

Greetings.

Answers to your questions Alex and Wendy:
1. I am using CVI 6.0 (we plan to migrate our development to CVI 7.1 in the near future). The problem has been observed on Windows NT4, 2000 and XP SP2. I reported it some time ago to the support team at NI Australia, who looked into it, but it was never resolved (to my knowledge).
2. To change the time zone during my tests, I used the Control Panel “Date and Time Properties” dialog. I usually access this by right-clicking on the clock display on the Windows taskbar, and selecting “Properties”.

I have done further testing today, and discovered that:
• The CVI and SDK methods both generate the correct result when the code is first executed.
• If the time zone is then changed, the results always differ; SDK is correct, CVI not.
• After I “Clear Interactive Declarations” and “Toggle Exclusion” in the Interactive Execution window and run again, both results are correct.

Is it possible that the run-time environment is not updated properly when the time zone is changed?

Regards,
Colin.

[Alex D]

Ok, I can reproduce this problem using the CVI 6.0 runtime engine. Using the CVI 7.1 runtime engine, the problem is not evident. Since the CVI RTE is free to download and backward compatible, I'd suggest that you install the new runtime engine which should resolve your issue (it did on my test machine).

The newest runtime engine can be downloaded from here.

Thanks for the help and sorry for the trouble!

Regards,

Alex

[cdk52]

That's good news, thanks Alex. I will try the new RTE.

If I find any problems with it, is there an easy way to revert to the previous version? What other issues are fixed in 7.1? Are there any known problems with apps developed under CVI 6.0?

Thanks again.

Colin.