Number of Years

[Gregc.]

G'day

I'm trying to work out the number of years since 1970, here is my code:

include <stdio.h>
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
return (seconds);
}
main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.

Thankyou

Greg

[John F]

"Gregc." wrote:

G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>
You missed # here.
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
This ends up as 31536000 which does not fit an int.
Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

since this is the only constant you are using.

int secToYear(int seconds) //Function Protoype
This is not a prototype. It is the implementation.
{
seconds = (SEC_IN_YEAR);
return (seconds);
OK... you take the parameter "seconds", assign a constant and return
that...?
I have no clue about what you intend to do here. I suppose some
calculations...
}
main () {
int main() would be the correct way since the standard requires main()
to return an int.
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));

return EXIT_SUCCESS;
}
For some reason the answer is coming out as 1. Could someone offer
me
some guidance.

Thankyou

Greg

regards
John

[osmium]

"Gregc." writes:

I'm trying to work out the number of years since 1970, here is my code:

include <stdio.h>
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
You are ignoring the parameter passed to the function,. You are simply
ignoring the value of now, which you provided in the caller, and overwriting
it. I suspect there is something else too, but this is the first thing I
notice.
return (seconds);
}
main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.

Thankyou

Greg

[Gregc.]

Thanks for your help. What I am trying to produce is 36 years ie
2006-1970.

Greg

John F wrote:

"Gregc." wrote:

G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>

You missed # here.

#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;

This ends up as 31536000 which does not fit an int.
Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

since this is the only constant you are using.

int secToYear(int seconds) //Function Protoype

This is not a prototype. It is the implementation.

{
seconds = (SEC_IN_YEAR);
return (seconds);

OK... you take the parameter "seconds", assign a constant and return
that...?
I have no clue about what you intend to do here. I suppose some
calculations...

}
main () {

int main() would be the correct way since the standard requires main()
to return an int.

time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));

return EXIT_SUCCESS;

}

For some reason the answer is coming out as 1. Could someone offer
me
some guidance.

Thankyou

Greg

regards
John

[Richard Heathfield]

John F said:

"Gregc." wrote:

int secToYear(int seconds) //Function Protoype
This is not a prototype.

Yes, it is.
It is the implementation.

That, too. But it *is* a prototype.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[John F]

"Richard Heathfield" wrote:

John F said:

"Gregc." wrote:

int secToYear(int seconds) //Function Protoype

This is not a prototype.

Yes, it is.

I knew that someone here would beat me up on this.

It is the implementation.

That, too. But it *is* a prototype.

In this case yes because of the top-down structure of his code.

Anyway to me a prototyoe does have a semicolon at the end of line...
;-)
Limits confusion of my students. I tell them ; following the bracket
indicates a declaration while an expression is a definition and that a
definition can substitute a declaration. That covers most cases, I
think.

regards
John

[Vladimir S. Oka]

On Sunday 12 March 2006 08:39, John F opined (in
<44***********************@tunews.univie.ac.at>) :

"Richard Heathfield" wrote:

John F said:

"Gregc." wrote:

int secToYear(int seconds) //Function Protoype

This is not a prototype.

Yes, it is.

I knew that someone here would beat me up on this.

It is the implementation.

That, too. But it *is* a prototype.

In this case yes because of the top-down structure of his code.

It always is. There just may be no code further below that uses it.
;-)

--
BR, Vladimir

Memory fault -- core...uh...um...core... Oh dammit, I forget!

[John F]

"Vladimir S. Oka" wrote:

On Sunday 12 March 2006 08:39, John F opined:

"Richard Heathfield" wrote:

John F said:

"Gregc." wrote:
>
> int secToYear(int seconds) //Function Protoype

This is not a prototype.

Yes, it is.

I knew that someone here would beat me up on this.

It is the implementation.

That, too. But it *is* a prototype.

In this case yes because of the top-down structure of his code.

It always is. There just may be no code further below that uses it.
;-)

Now you are picking peas ;-)

regards
John

[Nick Keighley]

Gregc. wrote:

I'm trying to work out the number of years since 1970, here is my code:

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

const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;

int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
return (seconds);
}

main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.

I must be missing something. Why not just calculate the current year
(use localtime()) then subtract 1970?

--
Nick Keighley

[Gregc.]

so would it be localtime()-1970?

[Rod Pemberton]

"Gregc." <gr*********@bigpond.com> wrote in message
news:11*********************@v46g2000cwv.googlegro ups.com...

G'day

I'm trying to work out the number of years since 1970, here is my code:
<snip>
For some reason the answer is coming out as 1. Could someone offer me
some guidance.

It's easier for me to show you. I'd also recommend buying or checking out
from a library:
"C: A Reference Manual," by Samuel Harbison and Guy Steele, Jr. of Tartan
Laboratories.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

struct tm es;
time_t esr;
int delta_years;

int main(void)
{
esr=time(NULL);
es=*localtime(&esr);
delta_years=1900+es.tm_year-1970;
/* Yes, I know I can just subtract 70. It may help the OP. */

printf("%d years since 1/1/1970\n",delta_years);
printf("%ld seconds since 1/1/1970\n",(unsigned long)esr);

exit(EXIT_SUCCESS);
}
Rod Pemberton

[Keith Thompson]

"Gregc." <gr*********@bigpond.com> writes:

so would it be localtime()-1970?

So *what* would be localtime()-1970?

You need to provide enough context so each followup makes sense on its
own. Read <http://cfaj.freeshell.org/google/> to learn how and why.

Going back to the previous article, the answer to your question is no.
Your system should provide documentation for the localtime() function.
If it doesn't, a Google search should find some documentation for it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-03-12, Gregc. <gr*********@bigpond.com> wrote:

G'day

I'm trying to work out the number of years since 1970, here is my code:

include <stdio.h>
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
return (seconds);
}
main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.

Thankyou

Greg

Have a close look at your secToYear() function. There's a start.

You have not programmed what you set out to get : you are simply
getting a constant.

Use a debugger or put a printf in your secToYear function : you are
setting seconds to a constant on each call.

Finally nowhere in your code are you doing a "difference" calculation.

Good luck!

[Keith Thompson]

"Gregc." <gr*********@bigpond.com> writes:

I'm trying to work out the number of years since 1970, here is my code:

include <stdio.h>
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
return (seconds);
}
main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.

Does it really? When I compile it (after adding the missing '#' on
the first line), I get:

tmp.c:6: error: initializer element is not constant
tmp.c:7: error: initializer element is not constant
tmp.c:8: error: initializer element is not constant

You're probably using a C++ compiler (C++ has different rules about
initializers than C).

The easiest fix for that is to move the const declarations inside the
secToYear() function. Also, "main ()" should be "int main(void)", and
you should have a "return 0;" at the end of your main function.

When I moved the const declarations inside the function, I got the
following output:

31536000 seconds since 1/1/1970

The program simply prints the value of SEC_IN_YEAR, which doesn't
match either the problem description, the message in the printf
statement, *or* the output you say it produced.

The program could be corrected to work the way you seemed to intend it
to work, but only by assuming that time() returns the number of
seconds since 1970-01-01. That's a common implementation, but it's
not guaranteed by the language, and you shouldn't depend on it if you
want your code to be portable (or if you want to post it here).

Is this the actual code you compiled? Did it really print 1 when you
ran it?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On 11 Mar 2006 21:33:46 -0800, in comp.lang.c , "Gregc."
<gr*********@bigpond.com> wrote:

(please don't snip attributions, its important to knwo who said what.
I've reinserted them for convenience)
(also, don't top post in CLC, it annoys the regulars and makes posts
hard to read)

John F said

Gregc said

>
> int secToYear(int seconds) //Function Protoype
> {
> seconds = (SEC_IN_YEAR);
> return (seconds);
OK... you take the parameter "seconds", assign a constant and return
that...?
I have no clue about what you intend to do here. I suppose some
calculations...

> For some reason the answer is coming out as 1. Could someone offer
> me

Thanks for your help. What I am trying to produce is 36 years ie
2006-1970.

Then do some calculations inside secToYear(). You might want to read
up on the functions in time.h, especially ones that convert to and
from a time_t and a struct tm. You might also want to look at the
contents of the struct tm.

Mark McIntyre
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Eric Sosman]

John F wrote:

"Gregc." wrote:

G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>

You missed # here.

#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;

This ends up as 31536000 which does not fit an int.

"Which might not fit in an int" would be better.
Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)

--
Eric Sosman
es*****@acm-dot-org.invalid

[John F]

"Eric Sosman" wrote:

John F wrote:

"Gregc." wrote:

G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>

You missed # here.

#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;

This ends up as 31536000 which does not fit an int.

"Which might not fit in an int" would be better.

Correct. Depends on the underlying width ... uint32_t would be better
in this case, if it exists.

Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)

Are you sure about this?

6.7.8 [4] could lead to this conclusion.
"All the expressions in an initializer for an object that has static
storage duration shall be constant expressions or string literals."

So one could argue that a multiplication of numeric literals is not a
constant expression?

Whereas [11] states: " The initializer for a scalar shall be a single
expression, optionally enclosed in braces. The initial value of the
object is that of the expression (after conversion); the same type
constraints and conversions as for simple assignment apply, taking the
type of the scalar to be the unqualified version of its declared
type."

So we look at assignment: 6.5.16
[3] "An assignment operator stores a value in the object designated by
the left operand. An assignment expression has the value of the left
operand after the assignment, but is not an lvalue. The type of an
assignment expression is the type of the left operand unless the left
operand has qualified type, in which case it is the unqualified
version of the type of the left operand."

6.5.16.1 [2] "In simple assignment (=), the value of the right operand
is converted to the type of the assignment expression and replaces the
value stored in the object designated by the left operand."

I read this as if 365*24*60*60 will be cast to long. especially since
it will be cast to long in case of multiplication. See 6.3.1.8

Comments requested (I want to gain on knowledge of the Standard:-)!
--
Eric Sosman
es*****@acm-dot-org.invalid

regards
John

[John F]

<Correction Reference to 6.3.1.8 does not deal with integer types>

"John F" <sp**@127.0.0.1> schrieb im Newsbeitrag
news:44***********************@tunews.univie.ac.at ...

"Eric Sosman" wrote:

John F wrote:

"Gregc." wrote:

G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>
You missed # here.
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
This ends up as 31536000 which does not fit an int.
"Which might not fit in an int" would be better.

Correct. Depends on the underlying width ... uint32_t would be
better in this case, if it exists.

Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)

Are you sure about this?

6.7.8 [4] could lead to this conclusion.
"All the expressions in an initializer for an object that has static
storage duration shall be constant expressions or string literals."

So one could argue that a multiplication of numeric literals is not
a constant expression?

Whereas [11] states: " The initializer for a scalar shall be a
single expression, optionally enclosed in braces. The initial value
of the object is that of the expression (after conversion); the same
type constraints and conversions as for simple assignment apply,
taking the type of the scalar to be the unqualified version of its
declared type."

So we look at assignment: 6.5.16
[3] "An assignment operator stores a value in the object designated
by the left operand. An assignment expression has the value of the
left operand after the assignment, but is not an lvalue. The type of
an assignment expression is the type of the left operand unless the
left operand has qualified type, in which case it is the unqualified
version of the type of the left operand."

6.5.16.1 [2] "In simple assignment (=), the value of the right
operand is converted to the type of the assignment expression and
replaces the value stored in the object designated by the left
operand."

I read this as if 365*24*60*60 will be cast to long. especially
since it will be cast to long in case of multiplication.

See 6.3.1.8
This reference is not correct. It takes care of float/double
conversion.
Sorry for this slipping in.

Comments requested (I want to gain on knowledge of the Standard:-)!

--
Eric Sosman
es*****@acm-dot-org.invalid

regards
John

[Eric Sosman]

John F wrote:

"Eric Sosman" wrote:

John F wrote:

"Gregc." wrote:
G'day

I'm trying to work out the number of years since 1970, here is my
code:

include <stdio.h>
You missed # here.

#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
This ends up as 31536000 which does not fit an int.
"Which might not fit in an int" would be better.

Correct. Depends on the underlying width ... uint32_t would be better
in this case, if it exists.

Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)

Are you sure about this?

Yes. All three multiplications follow the rules for `int'
arithmetic, after which the result is converted to `long'. If
the product is too large for `int', Evil Things will happen.
I'm feeling lazy at the moment and disinclined to hunt through
the Standard to figure out whether the Evil Things amount to
undefined behavior or to a guarantee of an implementation-
defined incorrect result; the fact that they're Evil is enough
for me.
I read this as if 365*24*60*60 will be cast to long. especially since
it will be cast to long in case of multiplication. See 6.3.1.8

There is no cast in what you showed. Adding a cast would
be one way to repair the problem:

const long SEC_IN_YEAR = (long)365 * 24 * 60 * 60;

Another would be to use one or more `long' numbers to begin
with:

const long SEC_IN_YEAR = 365L * 24 * 60 * 60;

As you noted in a follow-up, 6.3.1.8 doesn't apply here.

--
Eric Sosman
es*****@acm-dot-org.invalid

[John F]

"Eric Sosman" wrote:

John F wrote:

"Eric Sosman" wrote:

John F wrote:
[SNIP]
Use long instead.

why not just:

const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)
Are you sure about this?

Yes. All three multiplications follow the rules for `int'
arithmetic, after which the result is converted to `long'. If
the product is too large for `int', Evil Things will happen.

I can see it now. I usually do not encounter it on my 32 bit targets
where both long and int are 32 bits wide.
That's why I was not so sure at first. But you are right it is a
matter of portability.
I'm feeling lazy at the moment and disinclined to hunt through
the Standard to figure out whether the Evil Things amount to
undefined behavior or to a guarantee of an implementation-
defined incorrect result; the fact that they're Evil is enough
for me.
;-) well you are right. Evil is evil.

I read this as if 365*24*60*60 will be cast to long. especially
since
it will be cast to long in case of multiplication. See 6.3.1.8

There is no cast in what you showed. Adding a cast would
be one way to repair the problem:

const long SEC_IN_YEAR = (long)365 * 24 * 60 * 60;

Another would be to use one or more `long' numbers to begin
with:

const long SEC_IN_YEAR = 365L * 24 * 60 * 60;

Yes. That would put it on the safe side with "32 portable-street".
As you noted in a follow-up, 6.3.1.8 doesn't apply here.

I just misread the passage when parsing the standard.

thanks and regards
John

[Eric Sosman]

John F wrote:

"Eric Sosman" wrote:

John F wrote:

"Eric Sosman" wrote:
John F wrote:

[SNIP]

Use long instead.
>
>why not just:
>
>const long SEC_IN_YEAR=365*24*60*60;

Because if 31536000 does not fit in an int, this
will initialize SEC_IN_YEAR to the wrong value. (If
it manages to initialize SEC_IN_YEAR at all, that is:
this might be undefined behavior.)

Are you sure about this?

Yes. All three multiplications follow the rules for `int'
arithmetic, after which the result is converted to `long'. If
the product is too large for `int', Evil Things will happen.

I can see it now. I usually do not encounter it on my 32 bit targets
where both long and int are 32 bits wide.
That's why I was not so sure at first. But you are right it is a
matter of portability.

Strange how we can spot a problem in one context and then
completely miss the same flaw in another. You were the first
to mention that 31536000 might be too large for an `int',
suggesting you were well aware of the possiblity of an `int'
with fewer than ((runs a few logarithms)) 26 bits. And yet
you got tripped up by long experience with 32-bit `int' ...

Somewhere there's somebody working on a PhD thesis about
how to design programming languages/frameworks/what-have-you
so such oversights are harder to commit. Alas, I suspect the
PhD candidate is probably steeped in computer science when he
really ought to have a background in cognitive psychology ...

Meanwhile, I'll just keep kicking myself in the rear end
whenever I find I've made such a blunder. Unfortunately, it's
becoming uncomfortable to sit ...

--
Eric Sosman
es*****@acm-dot-org.invalid

[David Paleino]

Gregc. ha scritto:

G'day

I'm trying to work out the number of years since 1970, here is my code:

include <stdio.h>
#include <time.h>
const int SEC_IN_MIN = 60;
const int SEC_IN_HOUR = SEC_IN_MIN * 60;
const int SEC_IN_DAY = SEC_IN_HOUR * 24;
const int SEC_IN_YEAR = SEC_IN_DAY * 365;
int secToYear(int seconds) //Function Protoype
{
seconds = (SEC_IN_YEAR);
return (seconds);
}
main () {
time_t now = time(0);
printf("%i seconds since 1/1/1970\n",secToYear(now));
}

For some reason the answer is coming out as 1. Could someone offer me
some guidance.
Sure. :)
You could use this code:

---------------------------------------------------
#include <stdio.h>
#include <time.h>
#include <stdlib.h>

const int SEC_IN_YEAR = 31536000; /* Average seconds per year */

int main(void)
{
double years_r, months_r, days_r, hours_r, mins_r, secs_r;
/* "_r" stands for "raw" */
int years, months, days, hours, mins, secs;
time_t seconds;

seconds = time(NULL);

years_r = (double) seconds / SEC_IN_YEAR;
years = abs(years_r);

months_r = (years_r - (double)years) * 12;
months = abs(months_r);

days_r = (months_r - (double)months) * 30; /* Average days
per month... Who can write something better? */
days = abs(days_r);

hours_r = (days_r - (double)days) * 24;
hours = abs(hours_r);

mins_r = (hours_r - (double)hours) * 60;
mins = abs(mins_r);

secs_r = (mins_r - (double)mins) * 60;
secs = abs(secs_r);

printf("Years:\t%d\n", years);
printf("Months:\t%d\n", months);
printf("Days:\t%d\n", days);
printf("Hours:\t%d\n", hours);
printf("Mins:\t%d\n", mins);
printf("Secs:\t%d\n", secs);
printf("\n");
return 0;
}
---------------------------------------------------

It simply calculates years, months, days, hours, minutes and seconds
from 00:00:00 Jan 1, 1970 (also known as "Epoch").

If you just need the number of years, just delete all the code from
"months_r = (years_r ..." to "secs = abs(...". You should also fix the
variables declarations, and delete all those printfs...
Thankyou

No problem :)
Greg

David
P.S.: please tell me if this code is non-standard C... I've successfully
compiled it with `gcc -Wall -Wextra -ansi -pedantic'... (I'm just
learning C :P)
--
Linux Registered User #334216
Get FireFox! >> http://www.spreadfirefox.com/?q=affiliates&id=48183&t=1
Staff >> http://www.debianizzati.org <<

[John F]

"Eric Sosman" wrote:

John F wrote:

"Eric Sosman" wrote:

John F wrote:

"Eric Sosman" wrote:
>John F wrote:

[SNIP]

>>Use long instead.
>>
>>why not just:
>>
>>const long SEC_IN_YEAR=365*24*60*60;
>
> Because if 31536000 does not fit in an int, this
>will initialize SEC_IN_YEAR to the wrong value. (If
>it manages to initialize SEC_IN_YEAR at all, that is:
>this might be undefined behavior.)

Are you sure about this?

Yes. All three multiplications follow the rules for `int'
arithmetic, after which the result is converted to `long'. If
the product is too large for `int', Evil Things will happen.

I can see it now. I usually do not encounter it on my 32 bit
targets where both long and int are 32 bits wide.
That's why I was not so sure at first. But you are right it is a
matter of portability.

Strange how we can spot a problem in one context and then
completely miss the same flaw in another. You were the first
to mention that 31536000 might be too large for an `int',
suggesting you were well aware of the possiblity of an `int'
with fewer than ((runs a few logarithms)) 26 bits. And yet
you got tripped up by long experience with 32-bit `int' ...

That is what I call the convenience-effect. One gets used to code
messy really easily. I sometimes code for 8 bit. That's where reality
strikes back. This case shows that I need such a project again soon
:-)
Somewhere there's somebody working on a PhD thesis about
how to design programming languages/frameworks/what-have-you
so such oversights are harder to commit.
*chuckle* Nice. I'm wondering what the rest of the experts were doing
the past decades...
Alas, I suspect the
PhD candidate is probably steeped in computer science when he
really ought to have a background in cognitive psychology ...
That's an argument for comparative interdomain studies... I did a
small part of chaos theory back then. Seems to stick with me now ;-)
Meanwhile, I'll just keep kicking myself in the rear end
whenever I find I've made such a blunder. Unfortunately, it's
becoming uncomfortable to sit ...

To make it on topic... Seems to be proportional to the (Number of
Years) ;-)

I recently added an additional layer of abstraction to such actions.
(Besides it is quite hard to actually kick oneself into benamed
areas...)

[OT]
something like

struct rear_end {
/*log momentanous color here*/
double red,
double green,
double blue
};

struct damping {
/*soft filter characteristics*/
double factor,
double attack,
double decay
};

struct damped_rear {
struct rear_end rear,
struct damping *softstuff
};

union rear_u{
struct damped_rear damped,
struct rear_end undamped
};

/*Do some intermediate layer work here..*/
int ProtectedRear(union rear_u* MyRear);

/*Without protection:*/
int UnprotectedRear(union rear_u* MyRear);

You know what I mean?
[/OT]

regards
John

[Richard G. Riley]

On 2006-03-12, David Paleino <d.*******@gmail.com> wrote:

Gregc. ha scritto:

G'day

I'm trying to work out the number of years since 1970, here is my code:

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

Wouldnt you like to avoid all that nasty seconds stuff?

Take a look at localtime() and time()

struct tm *timeThen;
time_t t;
time(&t);
timeThen = localtime(&t);

There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}

The rest is trivial and a lot cleaner IMO.

[Keith Thompson]

David Paleino <d.*******@gmail.com> writes:

Gregc. ha scritto:

I'm trying to work out the number of years since 1970, here is my code:
[bad code snipped]
For some reason the answer is coming out as 1. Could someone offer me
some guidance.
Sure. :)
You could use this code:

---------------------------------------------------

[better code snipped] ---------------------------------------------------
If a beginning programmer is asking for help with a program, supplying
him with a complete solution might not be the best way to help him
learn.
It simply calculates years, months, days, hours, minutes and seconds
from 00:00:00 Jan 1, 1970 (also known as "Epoch"). [...] P.S.: please tell me if this code is non-standard C... I've successfully
compiled it with `gcc -Wall -Wextra -ansi -pedantic'... (I'm just
learning C :P)

I don't see anything non-standard in the code itself, but it does make
an assumption about the representation of time_t. On many systems,
time_t is a signed integer representing the number of seconds since
1970-01-01 00:00:00 GMT (I'd refer to it as UTC, but the UTC standard
wasn't introduced until some time after 1970). But the standard only
says that time_t is an arithmetic type capable of representing times.
Assuming that it's an integer type, or that its resolution is 1
second, or that 0 represents any particular epoch, or even that values
of time_t linearly and monotonically increase with increasing times,
is, strictly speaking, non-portable. You might never run across a
system that uses any other representation for time_t -- which means
that you might never detect the error by testing your code.

If you want to analyze time_t values portably, use localtime().

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, David Paleino <d.*******@gmail.com> wrote:

Gregc. ha scritto:

G'day

I'm trying to work out the number of years since 1970, here is my code:

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

Wouldnt you like to avoid all that nasty seconds stuff?

Take a look at localtime() and time()

struct tm *timeThen;
time_t t;
time(&t);
timeThen = localtime(&t);

There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}

Better yet, look at the actual specification of the "struct tm" type.
An implementation is allowed to provide extra members. Yours
apparently has done so; tm_gmtoff and tm_zone are non-standard.

The required members of struct tm, according to the C99 standard, are:

int tm_sec; // seconds after the minute -- [0, 60]
int tm_min; // minutes after the hour -- [0, 59]
int tm_hour; // hours since midnight -- [0, 23]
int tm_mday; // day of the month -- [1, 31]
int tm_mon; // months since January -- [0, 11]
int tm_year; // years since 1900
int tm_wday; // days since Sunday -- [0, 6]
int tm_yday; // days since January 1 -- [0, 365]
int tm_isdst; // Daylight Saving Time flag

The value of tm_isdst is positive if Daylight Saving Time is in
effect, zero if Daylight Saving Time is not in effect, and
negative if the information is not available.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, David Paleino <d.*******@gmail.com> wrote:

Gregc. ha scritto:
G'day

I'm trying to work out the number of years since 1970, here is my code:

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

Wouldnt you like to avoid all that nasty seconds stuff?

Take a look at localtime() and time()

struct tm *timeThen;
time_t t;
time(&t);
timeThen = localtime(&t);

There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}

Better yet, look at the actual specification of the "struct tm"

type.

Interesting point : the dump was more to show the "human readable
numbers", but I'm not so impressed with the man page definition
disagreeing with the compile time structure definition. Not that it
makes one iota of differenc for the problem in hand : possibly more
important in std.c.

But you would agree this is a tidier way of solving this problem?

[Default User]

Nick Keighley wrote:

I must be missing something. Why not just calculate the current year
(use localtime()) then subtract 1970?

That's what I was thinking. If I want to know how many years it's been
since, say, 1999, I don't go converting things to seconds. I compute
2006 - 1999 and get 7.

That assumes you only want whole years, which is what the OP's
follow-up post indicated.


Brian
--
If televison's a babysitter, the Internet is a drunk librarian who
won't shut up.
-- Dorothy Gambrell (http://catandgirl.com)

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes: [...]

There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}
Better yet, look at the actual specification of the "struct tm"

type.

Interesting point : the dump was more to show the "human readable
numbers", but I'm not so impressed with the man page definition
disagreeing with the compile time structure definition. Not that it
makes one iota of differenc for the problem in hand : possibly more
important in std.c.

What are you unimpressed about? The standard specifically says that
an implementation is allowed to add extra members. I don't know what
the man page says; it could follow either the standard or the
system-specific definition (if it does the latter, it should
acknowledge that two of the fields are implementation-defined.

Reading n1124 (or some other draft of the standard) would have avoided
this confusion.
But you would agree this is a tidier way of solving this problem?

If by "this" you mean using a debugger, no. If you mean using
localtime() rather than doing arithmetic on time_t values, I've
already addressed that point in this thread.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes: [...] There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}

Better yet, look at the actual specification of the "struct tm" type.

Interesting point : the dump was more to show the "human readable
numbers", but I'm not so impressed with the man page definition
disagreeing with the compile time structure definition. Not that it
makes one iota of differenc for the problem in hand : possibly more
important in std.c.

What are you unimpressed about? The standard specifically says that
an implementation is allowed to add extra members. I don't know

what

Sigh. Its not easy here.

I'm not impressed because the dcoumentaion is different from the
implementation on a live development system.
the man page says; it could follow either the standard or the
system-specific definition (if it does the latter, it should
acknowledge that two of the fields are implementation-defined.

Reading n1124 (or some other draft of the standard) would have avoided
this confusion.
It would : but wouldnt have made one iota of difference to *my*
system. And since the OPs requirement was contained within the
standard there was no confusion : until you bought one up.

But you would agree this is a tidier way of solving this problem?
If by "this" you mean using a debugger, no. If you mean using

Whyt would I be referring to using a debugger? Are you always this
purposely obtuse? Of course I'm referring to the use of localtime
instead of oodles of seconds calculations.
localtime() rather than doing arithmetic on time_t values, I've
already addressed that point in this thread.

'Fraid I never saw it.

[Jordan Abel]

On 2006-03-12, Richard G. Riley <rg****@gmail.com> wrote:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, David Paleino <d.*******@gmail.com> wrote:
Gregc. ha scritto:
> G'day
>
> I'm trying to work out the number of years since 1970, here is my code:
>
> include <stdio.h>
> #include <time.h>
>
>

Wouldnt you like to avoid all that nasty seconds stuff?

Take a look at localtime() and time()

struct tm *timeThen;
time_t t;
time(&t);
timeThen = localtime(&t);

There you have all your discrete time elements at your beck and
call. I cant vouch for platform independance though. In my debugger I
see:

$3 = {tm_sec = 17, tm_min = 23, tm_hour = 17, tm_mday = 12, tm_mon = 2,
tm_year = 106, tm_wday = 0, tm_yday = 70, tm_isdst = 0, tm_gmtoff = 3600,
tm_zone = 0x804a040 "CET"}
Better yet, look at the actual specification of the "struct tm"

type.

Interesting point : the dump was more to show the "human readable
numbers", but I'm not so impressed with the man page definition
disagreeing with the compile time structure definition. Not that it
makes one iota of differenc for the problem in hand

Some implementations have extensions that are "hidden" if certain macros
are enabled or disabled. gmtoff and zone are bsd extensions, i believe.
possibly more important in std.c.

But you would agree this is a tidier way of solving this problem?

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

[...]

What are you unimpressed about? The standard specifically says that
an implementation is allowed to add extra members. I don't know

what

Sigh. Its not easy here.

I'm not impressed because the dcoumentaion is different from the
implementation on a live development system.

Ok, so the documentation shows the members of struct tm that are
specified in the standard, but the implementation (for whatever
reason) has some extra members. I don't have a problem with that. It
might be nice for the man page to mention the extra members *if and
only if* it makes it clear that they're not standard, and that any
code that attempts to use them will be non-portable.

the man page says; it could follow either the standard or the
system-specific definition (if it does the latter, it should
acknowledge that two of the fields are implementation-defined.

Reading n1124 (or some other draft of the standard) would have avoided
this confusion.

It would : but wouldnt have made one iota of difference to *my*
system. And since the OPs requirement was contained within the
standard there was no confusion : until you bought one up.

You were the first one to mention the extra members (tm_gmtoff and
tm_zone) because you chose to show us the output of your debugger.

But you would agree this is a tidier way of solving this problem?

If by "this" you mean using a debugger, no. If you mean using

Whyt would I be referring to using a debugger? Are you always this
purposely obtuse? Of course I'm referring to the use of localtime
instead of oodles of seconds calculations.

You've been misunderstood enough times here that I'd think you'd allow
for the possibility that you're unclear.

localtime() rather than doing arithmetic on time_t values, I've
already addressed that point in this thread.

'Fraid I never saw it.

GIYF.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard G. Riley]

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote: [...]

What are you unimpressed about? The standard specifically says that
an implementation is allowed to add extra members. I don't know

what

Sigh. Its not easy here.

I'm not impressed because the dcoumentaion is different from the
implementation on a live development system.

Ok, so the documentation shows the members of struct tm that are
specified in the standard, but the implementation (for whatever
reason) has some extra members. I don't have a problem with that.

It

Thats a relief.
might be nice for the man page to mention the extra members *if and
only if* it makes it clear that they're not standard, and that any
code that attempts to use them will be non-portable.
Actually it should mention them all the time : otherwise how the hell
will the programmer know what the hell they're for on that platform?

the man page says; it could follow either the standard or the
system-specific definition (if it does the latter, it should
acknowledge that two of the fields are implementation-defined.

Reading n1124 (or some other draft of the standard) would have avoided
this confusion.
It would : but wouldnt have made one iota of difference to *my*
system. And since the OPs requirement was contained within the
standard there was no confusion : until you bought one up.

You were the first one to mention the extra members (tm_gmtoff and
tm_zone) because you chose to show us the output of your debugger.

Actually I never "mentioned them" directly : you bought attention to
them. I also mentioned that I couldnt state platform independance.
You bought them up just to make a point about the standards. Again.

So you have dragged a bit of sample code, that showed typical values
down to a slanging match over some platform independant fields which
had nothing to do with the required solution. I salute you.

But you would agree this is a tidier way of solving this problem?

If by "this" you mean using a debugger, no. If you mean using
Whyt would I be referring to using a debugger? Are you always this
purposely obtuse? Of course I'm referring to the use of localtime
instead of oodles of seconds calculations.

You've been misunderstood enough times here that I'd think you'd allow
for the possibility that you're unclear.

Yawn. Petty and spiteful. I am surprised. And also untrue. Want to be
confused? Dress up as a newbie and go back to that globals chat.

It was perfectly obvious that I didnt mean the debugger "solved the
problem". How the hell does a debugger make reference to the correct
data structure and write sample code to get the guy going? Do you have
a cupboard full of Pedant medals?

localtime() rather than doing arithmetic on time_t values, I've
already addressed that point in this thread.

'Fraid I never saw it.

GIYF.

Please dont use acronyms. It makes you angry.

--
Debuggers : you know it makes sense.
http://heather.cs.ucdavis.edu/~matlo...g.html#tth_sEc

[Keith Thompson]

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

"Richard G. Riley" <rg****@gmail.com> writes:

On 2006-03-12, Keith Thompson <ks***@mib.org> wrote:

[...]

What are you unimpressed about? The standard specifically says that
an implementation is allowed to add extra members. I don't know
what

Sigh. Its not easy here.

I'm not impressed because the dcoumentaion is different from the
implementation on a live development system.

Ok, so the documentation shows the members of struct tm that are
specified in the standard, but the implementation (for whatever
reason) has some extra members. I don't have a problem with that.

It

Thats a relief.

might be nice for the man page to mention the extra members *if and
only if* it makes it clear that they're not standard, and that any
code that attempts to use them will be non-portable.

Actually it should mention them all the time : otherwise how the hell
will the programmer know what the hell they're for on that platform?

Perhaps they're only used internally, and not intended for user code.

FILE is typically a struct. I don't expect man pages or other user
documentation to explain all the members, since they're not part of
the intended programmer interface.

the man page says; it could follow either the standard or the
system-specific definition (if it does the latter, it should
acknowledge that two of the fields are implementation-defined.

Reading n1124 (or some other draft of the standard) would have avoided
this confusion.

It would : but wouldnt have made one iota of difference to *my*
system. And since the OPs requirement was contained within the
standard there was no confusion : until you bought one up.

You were the first one to mention the extra members (tm_gmtoff and
tm_zone) because you chose to show us the output of your debugger.

Actually I never "mentioned them" directly : you bought attention to
them. I also mentioned that I couldnt state platform independance.
You bought them up just to make a point about the standards. Again.

So you have dragged a bit of sample code, that showed typical values
down to a slanging match over some platform independant fields which
had nothing to do with the required solution. I salute you.

You couldn't state platform independence. I could and did. I don't
know why you have a problem with that.

> But you would agree this is a tidier way of solving this problem?

If by "this" you mean using a debugger, no. If you mean using

Whyt would I be referring to using a debugger? Are you always this
purposely obtuse? Of course I'm referring to the use of localtime
instead of oodles of seconds calculations.

You've been misunderstood enough times here that I'd think you'd allow
for the possibility that you're unclear.

Yawn. Petty and spiteful. I am surprised. And also untrue. Want to be
confused? Dress up as a newbie and go back to that globals chat.

It was perfectly obvious that I didnt mean the debugger "solved the
problem". How the hell does a debugger make reference to the correct
data structure and write sample code to get the guy going? Do you have
a cupboard full of Pedant medals?

I truly wasn't entirely sure what you meant, so I covered both
possibilities. Again, I don't know why you have a problem with that,
or why you choose to share whatever problem you might have with the
rest of us.

localtime() rather than doing arithmetic on time_t values, I've
already addressed that point in this thread.

'Fraid I never saw it.

GIYF.

Please dont use acronyms. It makes you angry.

Nonsense.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Gregc.]

Basically what I am trying to achieve is calculate the number of years
since 1/1/1970 (which apparently is the start of unix), using in the
time_t (now) procedure.

Greg

[Richard Heathfield]

Gregc. said:

Basically what I am trying to achieve is calculate the number of years
since 1/1/1970 (which apparently is the start of unix), using in the
time_t (now) procedure.

Basically you can succeed in achieving this by calling time() to get the
current time as a time_t, passing it to localtime() to get a pointer to a
struct tm, and then looking at the struct's tm_year member, which contains
the number of years since 1900 (i.e. 106 this year). Clearly, the number of
years since 1970 will be that value - 70. To calculate fractions of a year,
look at the tm_mon and tm_mday members too, and do the obvious with them.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[ggrater]

Wow! Now that was a fun rant to read...programmers with *way* too much
time on their hands. Really guys...come on...36 messages and GregC
still does have a solid function to call. Thanks for wasting all of
our time...since 1970.

[Vladimir S. Oka]

gg*****@hotmail.com wrote:

Wow! Now that was a fun rant to read...programmers with *way* too much
time on their hands. Really guys...come on...36 messages and GregC
still does have a solid function to call.
If he still doesn't have one, despite all the advice he was given, then
he probably doesn't deserve one. But, how would you know? Did he
complain to you?
Thanks for wasting all of our time...since 1970.

You're welcome.

--
BR, Vladimir