mktime () is broken in ANSI Library

[hurst]

The function 'mktime ()' in the ANSI Library appears to be broken. It always returns a value of -1;

The attached test program demonstrates this fact.

NI, if you're listening, I need a fully functional 'mktime ()' for my application, like yesterday.

[Alex D]

There are two problems with the code you posted.

1. (not causing the problem you are seeing) The month field is 0-based, not one based, so it should be set to 2 for March. (offset by -1)

2. The year field is actually "the year minus 1900" (ie. a value of 0 is 1900) so it needs to be offset by -1900.

With these changes, the program works as expected.

Specifically:

insert this after the third fprintf:

  --new_time.tm_mon;
  new_time.tm_year -= 1900;

insert this before the fifth fprintf:

  ++loc_time->tm_mon;
  loc_time->tm_year += 1900;

Hope this helps!

Alex

Message Edited by Alex D on 03-10-2005 03:34 PM

[hurst]

Thanks that worked great except the hour is off by one. I am sure that this is due to Daylight Savings Time. Does the 'tm_isdst' field signify that the timezone honors DST or does it signify that we are in DST mode (October to April)? If I set the flag to '1' it will be correct now, but will it still be correct in May?

[Alex D]

You can use a little helper function to determine if DST should be set (something like this):

static int IsDSTActive(void)
{
	time_t test = time(NULL);
	struct tm *t = localtime(&test);
	return t->tm_isdst != 0;
}

[Alex D]

Oh! I missed your question. The is_dst field indicates if DST is active, not supported/enabled. That is, it should never always be one. If it is one but the current timezone doesn't use DST, that is probably fine.

Alex

[hurst]

What I really am attempting to do is determine a date and time in the future. but the base time may not neccessarily be the current date and time. So the question regarding DST applies to the base time and not the current time or the future time. It is very possible that the base time is in DST but the future time is NOT, and vice-versa. My example code just compiled all of the seperate operations together into one file for testing purposes, this is why the base date is in the form of a string (without DST information).

Hurst C.

[McGregorMortis]

I think mktime is broken too, but not the way the original poster thought.

Consider this code:
// Set up midnight, Jan. 1, 1970.
t.tm_year = 70;
t.tm_mon = 0;
t.tm_mday = 1;
t.tm_hour = 0;
t.tm_min = 0;
t.tm_sec = 0;
t.tm_isdst = 0;
tt = mktime(&t);

Since mktime is supposed to return time_t, seconds since 1970, obviously this should return 0. But it returns 2209006800. That works out

[McGregorMortis]

I think mktime is broken too, though not in the way the original poster thought. I'm trying to work out why the time_t values returned by the CVI code do not match the Seconds(False) function in TestStand 2.0.

Consider this code:
// Set up midnight, Jan. 1, 1970.
t.tm_year = 70; // Offset relative to 1900.
t.tm_mon = 0; // Zero-based.
t.tm_mday = 1;
t.tm_hour = 0;
t.tm_min = 0;
t.tm_sec = 0;
t.tm_isdst = 0;
tt = mktime(&t);

Since mktime is supposed to return time_t, seconds since 1970, obviously this should return 0. But it returns 2209006800. That works out almost exactly 70 years (ignoring leap years).

It seems like mktime() is expecting the year to be relative to 1970, not 1900.

[Alex D]

time_t is not defined to be seconds since Jan. 1, 1970 in the standard, although this is common. Actually, the base date is implementation defined. In the CVI ANSI library, the base date is Jan. 1, 1900.

Regards,

Alex

[McGregorMortis]

time() appears to be broken as well. Calling it right now, in LabWindows/CVI 6.0, it returns 3322497225. If you do the math, treating it as seconds since 1970 (which it should be), and ignoring leap years, that works out to somewhere around 2075. If you treat is as seconds since 1900 (incorrect), you get 2005.

So, time() and mktime() would give the appearance of working well, when tested against each other. But in fact, they both share the same bug.

Quite a headache this is all giving me.

- Ron