mktime returns too many seconds

[Eric]

I'm using mktime to try and get the number of seconds since 1970
to a specific date
I fill in a tm structure with time data
and call mktime(&tm) but i get a value back thats way too high
Sat Feb 21 21:10:01 2009 equates to 1,235,279,401 which is about
366 times what it should be if i am calculating this right
39 years * 86400 seconds should be about 3,369,600
My input tm values are:

tm.tm_sec = 1;
tm.tm_min = 10;
tm.tm_hour = 21;
tm.tm_mday = 21;
tm.tm_mon = 1; // 0 based, jan==0
tm.tm_year = 2009 - 1900;
tm.tm_isdst = -1;
printf("\"%d/%02d/%d %2d:%02d:%02d DST %d\"\n",
tm.tm_mon, tm.tm_mday, tm.tm_year,
tm.tm_hour, tm.tm_min, tm.tm_sec,
tm.tm_isdst);
printf("%ld\n", (long)mktime(&tm));


I get this output:
"1/21/109 21:10:01 DST -1"
1235279401

What am I missing?
Thanks
Eric

 

[Lew Pitcher]

I'm using mktime to try and get the number of seconds since 1970
to a specific date
I fill in a tm structure with time data
and call mktime(&tm) but i get a value back thats way too high
Sat Feb 21 21:10:01 2009 equates to 1,235,279,401 which is about
366 times what it should be if i am calculating this right
39 years * 86400 seconds should be about 3,369,600 [snip]
What am I missing?

It looks to me like your original assumptions are incorrect.

You say that you get a computed value that is

366 times what it should be

This last is suspicious to me; you say that /your/ result are 1/366 of the
computers result. 366 is a suspicious number to me; it is one more than
365, which is the number of days in a year.

So, let's look at how /you/ compute the number

39 years * 86400 seconds should be about 3,369,600

39 years? OK, that's good

86400 seconds? Nope. That's not the number of seconds in a year.
Let's see
86400 seconds / 60 seconds per minute = 1440 minutes
1440 minutes / 60 minutes per hour = 24 hours

It looks like you forgot to multiply by the number of days (24 hour periods)
in a year.

Thanks
Eric

HTH

PS: FWIW, one of the Unix "magic dates" passed recently. Unix time values
are calculated as the number of seconds since 1970-01-01 00:00:00 UTC (i.e.
the same as mktime would calculate). The magic number, passed this month,
was 1234567890 seconds past the start of the Unix epoch. This number looks
very close to your mktime-computed value of 1,235,279,401, being only
711511 (or 8.24 days) off.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Eric]

I'm using mktime to try and get the number of seconds since 1970
to a specific date
I fill in a tm structure with time data
and call mktime(&tm) but i get a value back thats way too high
Sat Feb 21 21:10:01 2009 equates to 1,235,279,401 which is about
366 times what it should be if i am calculating this right
39 years * 86400 seconds should be about 3,369,600 [snip]
What am I missing?

It looks to me like your original assumptions are incorrect.

You say that you get a computed value that is

366 times what it should be

This last is suspicious to me; you say that /your/ result are 1/366 of the
computers result. 366 is a suspicious number to me; it is one more than
365, which is the number of days in a year.

So, let's look at how /you/ compute the number

39 years * 86400 seconds should be about 3,369,600

39 years? OK, that's good

86400 seconds? Nope. That's not the number of seconds in a year.
Let's see
86400 seconds / 60 seconds per minute = 1440 minutes
1440 minutes / 60 minutes per hour = 24 hours

I think you have nailed it here - I did indeed forget to mulitply by 365
so the value i am seeing is ok - thanks!

 

[Eric]

Eric said:


mktime returns a time_t - if you want the number of seconds since
1970, your best best is difftime. (It may well be that, on your
platform, time_t /does/ represent the number of seconds since 1970,
but this assumption is not portable.)


Looks about right.


Suspicious yet?


That would be the number of seconds in 39 *days*, not 39 years.



A factor of approximately 365.25.

Yup, my bad!
Thanks

 

[Willem]

Eric wrote:
) I'm using mktime to try and get the number of seconds since 1970
) to a specific date
) I fill in a tm structure with time data
) and call mktime(&tm) but i get a value back thats way too high
) Sat Feb 21 21:10:01 2009 equates to 1,235,279,401 which is about
) 366 times what it should be if i am calculating this right

You're calculating it wrong.
Not too long ago, there was a celebration that the time reached 1234567890.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Keith Thompson]

I'm using mktime to try and get the number of seconds since 1970
to a specific date

[...]

As a sanity check, if you have the GNU version of the Unix "date"
program (part of the coreutils package), you can have it print the
number of seconds since 1970 for you:

% date +%s
1237666857
% date +%s -d '1980-01-01 00:00:00 UTC'
315532800

The "-d" option accepts dates in a fairly wide variety of formats.

 

[Martin Ambuhl]

Sat Feb 21 21:10:01 2009 equates to 1,235,279,401 which is about
366 times what it should be if i am calculating this right
39 years * 86400 seconds should be about 3,369,600

You really can't believe that a year is only one day long.

> What am I missing?

In addition to thinking that a day and a year are the same thing,
your

printf("%ld\n", (long) mktime(&tm));

carries several assumptions without basis in the C language.
See below:

#include <stdio.h>
#include <time.h>
#include <float.h>

int main(void)
{
time_t then_value, now_value;
struct tm then_struct, now_struct;
double dt;

then_struct.tm_sec = 0;
then_struct.tm_min = 0;
then_struct.tm_hour = 0;
then_struct.tm_mday = 1;
then_struct.tm_mon = 0;
then_struct.tm_year = 1970 - 1900;
then_struct.tm_isdst = -1;


now_struct.tm_sec = 1;
now_struct.tm_min = 10;
now_struct.tm_hour = 21;
now_struct.tm_mday = 21;
now_struct.tm_mon = 1;
now_struct.tm_year = 2009 - 1900;
now_struct.tm_isdst = -1;

printf("Values in then_struct before calling mktime()\n"
"\"%d/%02d/%d %2d:%02d:%02d DST %d\"\n\n",
then_struct.tm_mon, then_struct.tm_mday, then_struct.tm_year,
then_struct.tm_hour, then_struct.tm_min, then_struct.tm_sec,
then_struct.tm_isdst);


printf("Values in now_struct before calling mktime()\n"
"\"%d/%02d/%d %2d:%02d:%02d DST %d\"\n\n",
now_struct.tm_mon, now_struct.tm_mday, now_struct.tm_year,
now_struct.tm_hour, now_struct.tm_min, now_struct.tm_sec,
now_struct.tm_isdst);

#if 0
printf("%ld\n", (long) mktime(&tm));
/* There is no reason at all to expect that a now_t is any
human-interpretable meaning. To suggest that it represents seconds
is assuming an implementation-specific detail, as it is to suggest
that the epoch is Jan 1, 1970, or even that the values stored are
linear. */
#endif
then_value = mktime(&then_struct);
now_value = mktime(&now_struct);

printf("Values in then_struct after calling mktime()\n"
"\"%d/%02d/%d %2d:%02d:%02d DST %d\"\n",
then_struct.tm_mon, then_struct.tm_mday, then_struct.tm_year,
then_struct.tm_hour, then_struct.tm_min, then_struct.tm_sec,
then_struct.tm_isdst);
printf("This corresponds to %s\n", ctime(&then_value));


printf("Values in now_struct after calling mktime()\n"
"\"%d/%02d/%d %2d:%02d:%02d DST %d\"\n",
now_struct.tm_mon, now_struct.tm_mday, now_struct.tm_year,
now_struct.tm_hour, now_struct.tm_min, now_struct.tm_sec,
now_struct.tm_isdst);
printf("This corresponds to %s\n", ctime(&now_value));

printf("difftime reports that there is a %.*g second difference\n"
"between then and now.\n", DBL_DIG, dt =
difftime(now_value, then_value));
printf("That corresponds to %.*g days, \n"
"based on a 86400 sec day (rather than 86400.0028)\n",
DBL_DIG, dt /= 86400.);
printf("or %.*g equinoctial (tropical) years,\n"
"or %.*g anomalistc years,\n"
"or %.*g sidereal years,\n"
"or %.*g Gaussian years,\n"
"or %.*g Julian years.\n",
DBL_DIG, dt / 365.2421897,
DBL_DIG, dt / 365.259635,
DBL_DIG, dt / 365.256363,
DBL_DIG, dt / 365.25690, DBL_DIG, dt / 365.25);

return 0;
}


Values in then_struct before calling mktime()
"0/01/70 0:00:00 DST -1"

Values in now_struct before calling mktime()
"1/21/109 21:10:01 DST -1"

Values in then_struct after calling mktime()
"0/01/70 0:00:00 DST 0"
This corresponds to Thu Jan 1 00:00:00 1970

Values in now_struct after calling mktime()
"1/21/109 21:10:01 DST 0"
This corresponds to Sat Feb 21 21:10:01 2009

difftime reports that there is a 1235250601 second difference
between then and now.
That corresponds to 14296.8819560185 days,
based on a 86400 sec day (rather than 86400.0028)
or 39.1435665407701 equinoctial (tropical) years,
or 39.1416969904668 anomalistc years,
or 39.1420476253784 sidereal years,
or 39.1419900788144 Gaussian years,
or 39.14272951682 Julian years.

 

[Eric]

Jesus! I sure am glad i didnt make any more mistakes, you'd have gone on for
40 pages about how many angels can dance on the head of a pin.
Cant you be a little bit more succinct and just say "Hey - you forgot to
multiply by 365 days in a year, and oh by the way mktime returns a time_t
so you need to use a format specifier %<whatever> in printf.
You have to forgive me... I just dont have any edumacation and the treatise
below leaves me in the dust, just babbling to myself.
But thanks anyway man! I appreciate the effort!
Eric

 

[Kenny McCormack]

Jesus! I sure am glad i didnt make any more mistakes, you'd have gone on for
40 pages about how many angels can dance on the head of a pin.
Cant you be a little bit more succinct and just say "Hey - you forgot to
multiply by 365 days in a year, and oh by the way mktime returns a time_t
so you need to use a format specifier %<whatever> in printf.
You have to forgive me... I just dont have any edumacation and the treatise
below leaves me in the dust, just babbling to myself.

Your complaints are well-founded. Many of us have noted the same things,
many times over the years.

Or, to put it another way:

Welcome to Marty-world!

 

[Barry Schwarz]

Jesus! I sure am glad i didnt make any more mistakes, you'd have gone on for
40 pages about how many angels can dance on the head of a pin.
Cant you be a little bit more succinct and just say "Hey - you forgot to
multiply by 365 days in a year, and oh by the way mktime returns a time_t
so you need to use a format specifier %<whatever> in printf.
You have to forgive me... I just dont have any edumacation and the treatise
below leaves me in the dust, just babbling to myself.

He wrote one sentence for each mistake and then went to the trouble of
giving you a complete program which showed you how to eliminate those
mistakes. I guess some people need something to complain about.

If anything, his mistake was in helping you too much. Now, anyone
with the same homework problem (it comes up frequently) can find the
answer in the archives. If you wanted the pleasure of finding the
answer yourself (many of us get a sense of accomplishment from this),
you could have ignored the program.

 

[Antoninus Twink]

As a sanity check, if you have the GNU version of the Unix "date"
program (part of the coreutils package), you can have it print the
number of seconds since 1970 for you:

% date +%s
1237666857

Interesting, Keith.

So in your opinion are all the GNU coreutils "topical" on clc, or just
GNU date?

 

[Kenny McCormack]

He wrote one sentence for each mistake and then went to the trouble of
giving you a complete program which showed you how to eliminate those
mistakes. I guess some people need something to complain about.

Welcome to another episode of that whacky new hit show, so popular with
CLC regs:

Completely Missing The Point!

 

[Kenny McCormack]

Spend time reading this newsgroup, and you'll learn that Martin Ambuhl
is frequently obnoxious (you were rather fortunate in this case). However,
since Martin Ambuhl belongs to what has been described as a comp.lang.c
clique, his obnoxious manner is ignored on those occasions when he gets
something technically right. On the other hand, when people outside of
the comp.lang.c clique are obnoxious but technically right -- especially
when technically right against the statements of members of the
clique -- the members of the clique cry foul and want to focus on the
obnoxious behavior rather than on the technical merits.

That's one of the double standards on this newsgroup for which you'll
have to prepare yourself. Other double standards involve ideas about
topicality (who may violate it and who may not), ideas about trolling (who
may do it and who may not), ideas about technical accuracy (who may play
loose and who may not), and ideas about commercial products (who may
plug them and who may not).

Indeed, very well written and insightful.

Also check out: http://www.imdb.com/title/tt0083482/quotes

Where you will find:

Lauren Hutchinson: [during opening credits] Listen, I've
got this whole high school thing psyched out. It all breaks down into
cliques.

Patty Greene: Cliques?

Lauren Hutchinson: Yeah, you know, cliques; little in-groups of
different kids. All we have to do is click with the right clique and we
can finally have a social life that's worthy of us.

That's CLC in a nutshell.

 

[Bartc]

He wrote one sentence for each mistake and then went to the trouble of
giving you a complete program which showed you how to eliminate those
mistakes. I guess some people need something to complain about.

You don't think the following was over-the-top:

That corresponds to 14296.8819560185 days,
based on a 86400 sec day (rather than 86400.0028)
or 39.1435665407701 equinoctial (tropical) years,
or 39.1416969904668 anomalistc years,
or 39.1420476253784 sidereal years,
or 39.1419900788144 Gaussian years,
or 39.14272951682 Julian years.

I'm still not sure what mistake of the OP's this was supposed to address. Or
the point of it at all.