current time

[Tim Quon]

Hi

I need to print the current time.

I found an example where this is done as followed:
long *mytime;
time(mytime);
printf("time: %s", ascitime(mytime);

But this doesn't work and prints some ugly numbers.

How is this done correctly?

 

[Jirka Klaue]

I need to print the current time.

I found an example where this is done as followed:
long *mytime;
time(mytime);
printf("time: %s", ascitime(mytime);

At least 6 errors in these 3 lines!

time_t mytime = time(0);
printf("time: %s\n", asctime(localtime(&mytime)));

Jirka

 

[Richard Bos]

I found an example where this is done as followed:
long *mytime;
time(mytime);
printf("time: %s", ascitime(mytime);

But this doesn't work and prints some ugly numbers.

How is this done correctly?

No kiddin'. What is time()'s prototype? What is asctime()'s? (And note,
ascitime() doesn't exist...) In particular, what kind of parameters do
these functions take?

Richard

 

[Tim Quon]

At least 6 errors in these 3 lines!

time_t mytime = time(0);
printf("time: %s\n", asctime(localtime(&mytime)));

Jirka

Thanks a lot.
Never trust examples from the web :')

 

[Martin Ambuhl]

Hi

I need to print the current time.

I found an example where this is done as followed:
long *mytime;
time(mytime);
printf("time: %s", ascitime(mytime);

But this doesn't work and prints some ugly numbers.

How is this done correctly?

asctime() [note spelling] requires a pointer to a struct tm.
You could get such a pointer from localtime(), among others.
ctime() is probably the function you want, which takes a pointer to time_t
as its argument.
#include <time.h>
#include <stdio.h>

void shortime(void)
{
time_t mytime = time(0); /* not 'long' */
printf("time: %s", ctime(&mytime));
}

 

[Al Bowers]

Hi

I need to print the current time.

I found an example where this is done as followed:
long *mytime;
time(mytime);
printf("time: %s", ascitime(mytime);

But this doesn't work and prints some ugly numbers.

How is this done correctly?

No, not even close to being correct.
time_t mytime;
time(&mytime);
or
mytime = time(NULL);
And to print the date-time use function ctime.

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

int main(void)
{
time_t now;

if((now = time(NULL)) == (time_t)-1)
puts("Failure in getting time");
else
printf("The date and time is: %s",ctime(&now));
return 0;
}



--

 

[SW1]

Well i think what you saw is the C time which counts the seconds since
January the first, 1970. There is a function in time.h which is called
localtime, it works like that:

time_t now; //time_t should be declared in time.h as long
struct tm *current; //pointer to array holding the current time

now = time(0); //current time in C representation
current = localtime(&now); //IMPORTANT you have to use a pointer to
time_t
printf("%i\n",current->tm_min); //Lets print the current minute

So now struct tm has money members:

struct tm {
int tm_sec; /* seconds after the minute - [0,59] */
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 savings time flag */
};

I hope that helped

 

[Martin Ambuhl]

Well i think what you saw is the C time which counts the seconds since
January the first, 1970. There is a function in time.h which is called
localtime, it works like that:

Not necessarily. For at least these reasons:
time_t (and clock_t) are arithmetic types capable of representing times.
There is no requirement about which arithmetic type, what the encoding is
(so linearity is not required), what the granularity is (so "seconds" are
not required), or what the base epoch is (so no particular date -- and
certainly not 1/1/1970 -- is specified).

time_t now; //time_t should be declared in time.h as long

Wrong. See above.

[ ... ]

I hope that helped

Only if he ignores your errors.

 

[SW1]

Not necessarily. For at least these reasons:
time_t (and clock_t) are arithmetic types capable of representing times.
There is no requirement about which arithmetic type, what the encoding is
(so linearity is not required), what the granularity is (so "seconds" are
not required), or what the base epoch is (so no particular date -- and
certainly not 1/1/1970 -- is specified).

Hmm, You might want to risk a look into time.h it says there:
typedef long time_t;
and if you call the time() function you get the SECONDS since 1/1/1970
passed to it.

SOO

now anyway the program would still run and print the current time,
even if I was wrong about time() and time_t.

THNX

 

[Irrwahn Grausewitz]

Hmm, You might want to risk a look into time.h it says there:
typedef long time_t;
and if you call the time() function you get the SECONDS since 1/1/1970
passed to it.

Not necessarily so, it actually depends on the implementation - lookup
the standard. Quote from n843:

7.23.2.5 The time function

[...]

Returns

[#3] The time function returns the implementation's best
approximation to the current calendar time. The value
(time_t)-1 is returned if the calendar time is not
available. If timer is not a null pointer, the return value
is also assigned to the object it points to.

<SNIP>

Regards

Irrwahn

 

[Kevin Easton]

Hmm, You might want to risk a look into time.h it says there:

There is no one true time.h.

- Kevin.

 

[Al Bowers]

Hmm, You might want to risk a look into time.h it says there:
typedef long time_t;
and if you call the time() function you get the SECONDS since 1/1/1970
passed to it.

You should be aware that your implementations time.h and compiler
does not define the language. The language is defined by ISO/IEC 9899.
This standard says in regards to time_t, that is is an arithmetic
type capable of representing times. The range and precision of
time_t is implementation defined. Thus the range, long on your
implementation, may be different on other implementations. And,
your precision, seconds, may be different on other implementations.

SOO

now anyway the program would still run and print the current time,
even if I was wrong about time() and time_t.

Soo, you should avoid asserting that time_t should be type long and
the precision is seconds since some date in 1970. These may be true
for your implementation of the language but there are many in this
newsgroup who have implementations of the language that do not use
your asserted range and/or precision.

 

[Christopher Benson-Manica]

There is no one true time.h.

The time.h that can be known is not the true time.h?

 

[Joona I Palaste]

The time.h that can be known is not the true time.h?

And so Christopher was enlightened.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"My absolute aspect is probably..."
- Mato Valtonen

 

[Keith Thompson]

Soo, you should avoid asserting that time_t should be type long and
the precision is seconds since some date in 1970. These may be true
for your implementation of the language but there are many in this
newsgroup who have implementations of the language that do not use
your asserted range and/or precision.

Quite correct.

Note that the convention of making time_t an integer type with
one-second granularity, with 0 representing midnight 1970-01-01, goes
back to the early days of Unix and C (before the ANSI/ISO C standard).
This convention spread to many other implementations. I've seen
implementations where time_t is a 64-bit type, and ones where it's
unsigned rather than signed, but I don't believe I've ever used one
with a granularity other than 1 second or an epoch other than
1970-01-01.

That's not, of course, to say that such implementations don't exist,
just that it's all to easy to assume that they don't. Writing
portable code isn't just about making it work on every implementation
you've seen; you have to understand the standard and avoid making any
unjustified assumptions about implementations you haven't seen.

 

[lawrence.jones]

I've seen
implementations where time_t is a 64-bit type, and ones where it's
unsigned rather than signed, but I don't believe I've ever used one
with a granularity other than 1 second or an epoch other than
1970-01-01.

I have. SAS/C for the IBM mainframe uses double for time_t; the units
are seconds from the epoch, but the floating type allows subsecond
resolution. When I used it, the epoch was 1900-01-01, but recent
releases default to 1970-01-01 to conform to POSIX (it's a global
variable so you can set it to whatever you want).

-Larry Jones

I never get to do anything fun. -- Calvin

 

[Lew Pitcher]

I have. SAS/C for the IBM mainframe uses double for time_t; the units
are seconds from the epoch, but the floating type allows subsecond
resolution. When I used it, the epoch was 1900-01-01,

which would be consistant with the 'native' epoch of the mainframe. MVS and
VSE both use 00:00:00 1900-01-01 as the beginning of their epoch. I don't know
about zOS or OS390, but both MVS and VSE used a 32bit unsigned binary number
(an S/390 "fullword") that was incremented about (IIRC) 300 times per second.

but recent
releases default to 1970-01-01 to conform to POSIX (it's a global
variable so you can set it to whatever you want).

Which would be consistant with IBM's ongoing evolution of the mainframe support.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Keith Thompson]

which would be consistant with the 'native' epoch of the
mainframe. MVS and VSE both use 00:00:00 1900-01-01 as the beginning
of their epoch. I don't know about zOS or OS390, but both MVS and VSE
used a 32bit unsigned binary number (an S/390 "fullword") that was
incremented about (IIRC) 300 times per second.

That would wrap around in less than 6 months. Are you sure it's not a
64-bit number?

 

[Lew Pitcher]

That would wrap around in less than 6 months. Are you sure it's not a
64-bit number?

You are, of course, correct. It wasn't a "Word"[1] value (32bits), it was a
"DoubleWord"[2] (64bit) value.


[1] "Word" here is IBM's term for a 32bit binary value. When stored, the high
8bits must be stored aligned on a two-octet (even address) boundary.
[2] "DoubleWord" here is IBM's term for a 64bit binary value. When stored,
the high 8bits must be stored aligned on a four-octet (even address) boundary.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.