By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,537 Members | 1,743 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,537 IT Pros & Developers. It's quick & easy.

Getting time in milliseconds

P: n/a
Hi:
is there a way to get current system time in milliseconds...
which functions and headers??

thanks
pravesh
Nov 14 '05 #1
Share this Question
Share on Google+
26 Replies


P: n/a
"Pravesh" <pr****************@yahoo.com> wrote in message
news:e5**************************@posting.google.c om...
Hi:
is there a way to get current system time in milliseconds...
Not portably.
which functions and headers??


The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.

-Mike
Nov 14 '05 #2

P: n/a
> > Pravesh:
is there a way to get current system time in milliseconds...
"Mike Wahler" wrote:
Not portably. which functions and headers??

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.


But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct? In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ
Nov 14 '05 #3

P: n/a

"Merrill & Michele" <be********@comcast.net> wrote in message
news:er********************@comcast.com...
Pravesh:
is there a way to get current system time in milliseconds...
"Mike Wahler" wrote:
Not portably. which functions and headers??

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.


But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct?


It's entirely possible that I would. "Arbitrary machine" might not
have the requested functionality. Or perhaps a C translator for it
does not exist.
In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ


Some platforms, operating systems, and C implementations do provide
the requested functionality, others do not. Also note that a C program
need not be hosted by an operating system at all.

-Mike
Nov 14 '05 #4

P: n/a
On Mon, 8 Nov 2004 19:34:34 -0600, "Merrill & Michele"
<be********@comcast.net> wrote in comp.lang.c:
Pravesh:
is there a way to get current system time in milliseconds...
"Mike Wahler" wrote:
Not portably.

which functions and headers??

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.


But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine,"
you wouldn't get your brains blown out, correct? In particular, is this not
true if you let a program "warm up" to an OS for, say, a minute? MPJ


Sure, you can always multiply the return value of difftime() by 1000.

But there are a lot of systems out there that don't track time
accurately to the millisecond.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 14 '05 #5

P: n/a
> Pravesh:
> is there a way to get current system time in milliseconds...
"Mike Wahler" wrote:
Not portably.

> which functions and headers??

The standard functions for retrieving system time and
working with time are declared by the header <time.h>.
They including 'time()', 'localtime()', and 'gmtime()',
among others. However, the resolution of the time
is implementation-specific.


But if, conjecturally, some one put a gun to your head and said "I need
milliseconds from the arbitrary machine using C compiled on said machine," you wouldn't get your brains blown out, correct? In particular, is this not true if you let a program "warm up" to an OS for, say, a minute?

Jack Klein:
Sure, you can always multiply the return value of difftime() by 1000.

But there are a lot of systems out there that don't track time
accurately to the millisecond.


That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. The
following code is crude, but I think it illustrates that one isn't shackled
by notions smaller than a second. I think I recall that a "jiffy" is 10^-52
seconds. MPJ

#include <stdio.h>
#include <time.h>
int main (){
time_t timer;
long i, counter, aboutbillion, fiveseconds;
aboutbillion = 0;
counter = 0;
fiveseconds = (long)(time(&timer) + 5);
while (aboutbillion < fiveseconds){
aboutbillion = (long)time(&timer);
++counter;
}
printf (" counter= %ld\n", counter);
printf (" timer= %ld\n", aboutbillion);
printf (" and five= %ld\n", fiveseconds);
return 0;
}
Nov 14 '05 #6

P: n/a
pr****************@yahoo.com (Pravesh) wrote in message news:<e5**************************@posting.google. com>...
Hi:
is there a way to get current system time in milliseconds...
which functions and headers??

Short reply:in C, no.

Long reply:But there are libraries that define certain structures and functions
that let you manipulate time values.That is system/implementation dependant.Also
you will need to know why and where you are using it.And that's exactly OT here.
E.g:if you are on *nix systems you can probably find something like time.h,
look up on it.And Google for it!There are lots of resources available.

HTH
Suman.
Nov 14 '05 #7

P: n/a
Jack Klein wrote:
Sure, you can always multiply the return value of difftime() by 1000.


And then divide the result by 1000000.
Christian

Nov 14 '05 #8

P: n/a
pr****************@yahoo.com (Pravesh) wrote in message news:<e5**************************@posting.google. com>...
Hi:
is there a way to get current system time in milliseconds...
which functions and headers??
Yes, there is Fucntion to compute/get time of the specified fuction.
(How much fucntion is taking time to execute),I think this is your Goal.

for linux --> #include <sys/time.h>
gettimeofday

for windows --> #include <time.h>
GetTickCount is the function
See the both the arguments in it
and You will be able to get the Time in milliseconds
Hope this will help you out.
If You have the problem then drop the mail.

Enjoy
Ranjeet
thanks
pravesh

Nov 14 '05 #9

P: n/a
Merrill & Michele <be********@comcast.net> wrote:
Jack Klein:
Sure, you can always multiply the return value of difftime() by 1000.

But there are a lot of systems out there that don't track time
accurately to the millisecond.
That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. The
following code is crude, but I think it illustrates that one isn't shackled
by notions smaller than a second. I think I recall that a "jiffy" is 10^-52
seconds. MPJ #include <stdio.h>
#include <time.h>
int main (){
time_t timer;
long i, counter, aboutbillion, fiveseconds;
aboutbillion = 0;
counter = 0;
fiveseconds = (long)(time(&timer) + 5);
There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times".
while (aboutbillion < fiveseconds){
aboutbillion = (long)time(&timer);
++counter;
}
printf (" counter= %ld\n", counter);
printf (" timer= %ld\n", aboutbillion);
printf (" and five= %ld\n", fiveseconds);
return 0;
}


Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.
Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #10

P: n/a
ra***********@gmail.com (ranjeet) wrote:
pr****************@yahoo.com (Pravesh) wrote in message news:<e5**************************@posting.google. com>...
is there a way to get current system time in milliseconds...
which functions and headers??
Yes, there is Fucntion to compute/get time of the specified fuction.


Not in ISO C, there isn't.
(How much fucntion is taking time to execute)
That's not what he asked for.
for linux --> #include <sys/time.h>
gettimeofday

for windows --> #include <time.h>
GetTickCount is the function


Now please answer the question for the Sinclair QL. And then for my
microwave controller.

Richard
Nov 14 '05 #11

P: n/a
In article <news:u-********************@comcast.com>
Merrill & Michele <be********@comcast.net> wrote:
That systems don't track milliseconds doesn't mean that we can't track THEM
to the millisecond. That is, with a little elbow grease and the view that
the occurence of the next second can be seen as a Poisson process. ...


Except that time is *not* a Poisson process. Time is isochronous
(by definition), and isochronous processes are not Poisson. (Events
in a Poisson process are characterized by an exponential probability
distribution.)

This distinction can actually matter, as Steve McCanne and I showed
in a paper given at a Usenix in the 1990s. Unix-like systems whose
scheduler is driven from the same clock as their "random" (actually
not random at all!) sampling clock provide just what is needed to
write programs whose resource usage is systematically mismeasured.
This sort of mis-measuring can and does occur "by accident", as
well as on purpose in our "hog.c" program (which uses more than
90% of the available CPU time, even though "ps" commands show it
using under 5%).

To get accurate measurements, many modern CPUs provide a clock-cycle
counter. Using it requires a lot of careful attention to details,
all of which are, unfortunately, off-topic in comp.lang.c. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #12

P: n/a
> >> Jack Klein: But there are a lot of systems out there that don't track
time
accurately to the millisecond.
MPJ: That systems don't track milliseconds doesn't mean that we can't track THEM to the millisecond. That is, with a little elbow grease and the view that the occurence of the next second can be seen as a Poisson process. The
following code is crude, but I think it illustrates that one isn't shackled by notions smaller than a second. I think I recall that a "jiffy" is 10^-52 seconds.
Jens Toerring:
There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times". Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.


If I get you correctly, then all this stuff I just lifted from time.h is OS
stuff.

#ifndef _TM_DEFINED
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 */
};
#define _TM_DEFINED
#endif
/* Clock ticks macro - ANSI version */

#define CLOCKS_PER_SEC 1000

An arithmetic type capable of representing time. So kann die Zeit nicht
dargestellt werden. MPJ
Nov 14 '05 #13

P: n/a
"Merrill & Michele" <be********@comcast.net> wrote:

[ BTW, _please_ use proper attribution lines. ]
There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times".
Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.


If I get you correctly, then all this stuff I just lifted from time.h is OS
stuff.


You don't get him correctly; what you quote has nothing whatsoever to do
with time().
#ifndef _TM_DEFINED
_This_ line is implementation-specific, as are the related lines below.
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 */
};
These members of struct tm, however, are perfectly defined in the
Standard. Their order is not specified, and struct tm could have other
members, but those listed here are required.
However, struct tm is used by several functions, but _not_ by time().
/* Clock ticks macro - ANSI version */

#define CLOCKS_PER_SEC 1000
CLOCKS_PER_SEC is indeed ISO (not just ANSI!) C, but its value is
implementation-specific. Moreover, it's not used with time(), but with
clock().
An arithmetic type capable of representing time. So kann die Zeit nicht
dargestellt werden.


Oh, doch, kann sie. But you'll need to use something like ctime() to get
a human-readable representation from it, and you cannot depend on having
any particular resolution.

Richard
Nov 14 '05 #14

P: n/a
"Richard Bos" wrote:
[ BTW, _please_ use proper attribution lines. ]
I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).
There's nothing that guarantees that time_t is a time in seconds on
all systems, at least the C standard does only says that time_t is
a "arithmetic type capable of representing times".

Even if time_t does return times in seconds that won't do you any
good on a multi-tasking OS. What you try to do here is measure the
time a call of time() takes - but that will only give you a useful
result if the process gets all the CPU time during that 5 seconds.
But on most modern operating systems the CPU time gets distributed
between different processes, and the OS itself uses some time for
it's own purposes. So you don't have a chance to get a reproducible
value that way since you don't have any idea how much time the other
processes get (you don't even know how many there are) and how much
time the OS is going to need.


If I get you correctly, then all this stuff I just lifted from time.h is OS stuff.


You don't get him correctly; what you quote has nothing whatsoever to do
with time().


I freely admit that I don't get him correctly; I'm trying to determine how
far out in left field I actually am. Wouldn't you expect a declaration of
time_t in time.h?
_This_ line is implementation-specific, as are the related lines below.
These members of struct tm, however, are perfectly defined in the
Standard. Their order is not specified, and struct tm could have other
members, but those listed here are required.
However, struct tm is used by several functions, but _not_ by time().
Because time() is a system call (?)
/* Clock ticks macro - ANSI version */

#define CLOCKS_PER_SEC 1000


CLOCKS_PER_SEC is indeed ISO (not just ANSI!) C, but its value is
implementation-specific. Moreover, it's not used with time(), but with
clock().
An arithmetic type capable of representing time. So kann die Zeit nicht
dargestellt werden.


Oh, doch, kann sie. But you'll need to use something like ctime() to get
a human-readable representation from it, and you cannot depend on having
any particular resolution.


I'm obviously no match for this topic yet. I should get back to K&R. MPJ
Nov 14 '05 #15

P: n/a
Merrill & Michele <be********@comcast.net> scribbled the following:
"Richard Bos" wrote:
[ BTW, _please_ use proper attribution lines. ]
I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).
The established form is:

==========================cut here============================
Foo wrote: Bar wrote:
Baz wrote:
Quux wrote:
Yeah, well is that so? Yes, it is, as a matter of fact.
Then my original message was incorrect.

Don't worry, we all make mistakes.


Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Hasta la Vista, Abie!"
- Bart Simpson
Nov 14 '05 #16

P: n/a

"Chris Torek" <no****@torek.net> wrote in message
news:cm*********@news2.newsguy.com...
In article <news:u-********************@comcast.com>
Merrill & Michele <be********@comcast.net> wrote:
That systems don't track milliseconds doesn't mean that we can't track THEMto the millisecond. That is, with a little elbow grease and the view thatthe occurence of the next second can be seen as a Poisson process. ...


Except that time is *not* a Poisson process. Time is isochronous
(by definition), and isochronous processes are not Poisson. (Events
in a Poisson process are characterized by an exponential probability
distribution.)

This distinction can actually matter, as Steve McCanne and I showed
in a paper given at a Usenix in the 1990s. Unix-like systems whose
scheduler is driven from the same clock as their "random" (actually
not random at all!) sampling clock provide just what is needed to
write programs whose resource usage is systematically mismeasured.
This sort of mis-measuring can and does occur "by accident", as
well as on purpose in our "hog.c" program (which uses more than
90% of the available CPU time, even though "ps" commands show it
using under 5%).

To get accurate measurements, many modern CPUs provide a clock-cycle
counter. Using it requires a lot of careful attention to details,
all of which are, unfortunately, off-topic in comp.lang.c. :-)


I would say that it is more to the point a Poisson process is characterized
by a failure rate, lamba, which as I think to recall was also the expected
value. The failure is that time() is no longer equal to itself. If I ran
my little program time ditty for 2 seconds, 5 seconds and thirty seconds,
and then did a little figuring, I bet I could get 60 seconds within a
millisecond. MPJ
Nov 14 '05 #17

P: n/a

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:cm**********@oravannahka.helsinki.fi...
Merrill & Michele <be********@comcast.net> scribbled the following:
"Richard Bos" wrote:
[ BTW, _please_ use proper attribution lines. ]
I thought I worked hard to get the right author attributed with the correct number of greater than signs. Is this not what is desired? Apparently, you omit them entirely (?).


The established form is:

==========================cut here============================
Foo wrote:
Bar wrote:
Baz wrote:
Quux wrote:
> Yeah, well is that so?

Yes, it is, as a matter of fact. Then my original message was incorrect.

Don't worry, we all make mistakes.


Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.


The links for messages and e-mail get snipped?
Nov 14 '05 #18

P: n/a
Merrill & Michele <be********@comcast.net> wrote:
"Richard Bos" wrote:
[ BTW, _please_ use proper attribution lines. ]
I thought I worked hard to get the right author attributed with the correct
number of greater than signs. Is this not what is desired? Apparently, you
omit them entirely (?).
> > There's nothing that guarantees that time_t is a time in seconds on
> > all systems, at least the C standard does only says that time_t is
> > a "arithmetic type capable of representing times".
>
> If I get you correctly, then all this stuff I just lifted from time.h is
> OS stuff.


You don't get him correctly; what you quote has nothing whatsoever to do
with time(). I freely admit that I don't get him correctly; I'm trying to determine how
far out in left field I actually am. Wouldn't you expect a declaration of
time_t in time.h?
That's not the point. 'time_t' can very well be typedef'ed in <time.h>.
But what 'struct tm' is is unrelated to what 'time_t' is - and that
was what you were using in your program. 'struct tm' is something
used to represent times in some (more or less) human-readable form,
while 'time_t' is just some "arithmetic type" that can represent
times in some compacter and more system dependend way. To get it
into a more useful representation you have e.g. ctime(), gmtime()
and localtime(). While a 'time_t' value is often the time in seconds
since some date taken as the zero point, it could also be the time
since then in microsends, nanoseconds or also hours, dependend on
what the systems time resolution allows and what the implementors
thought to be useful.
_This_ line is implementation-specific, as are the related lines below.
These members of struct tm, however, are perfectly defined in the
Standard. Their order is not specified, and struct tm could have other
members, but those listed here are required.
However, struct tm is used by several functions, but _not_ by time().

Because time() is a system call (?)


No, because things were defined that way. time() were probably defined
the way it is because its return value doesn't need much space (when
compared to a 'struct tm' structure) and it's probably fast since it
can store the value in a way that's near to (or even identical with)
the underlying hardware representation of a time, while to get the
time into the 'struct tm' you need a lot of calculations.

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de
Nov 14 '05 #19

P: n/a
Merrill & Michele <be********@comcast.net> scribbled the following:
"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:cm**********@oravannahka.helsinki.fi...
Merrill & Michele <be********@comcast.net> scribbled the following:
>> "Richard Bos" wrote:
>> [ BTW, _please_ use proper attribution lines. ]
> I thought I worked hard to get the right author attributed with the correct > number of greater than signs. Is this not what is desired? Apparently, you > omit them entirely (?).


The established form is:

==========================cut here============================
Foo wrote:
> Bar wrote:
>> Baz wrote:
>>> Quux wrote:
>>>> Yeah, well is that so?

>>> Yes, it is, as a matter of fact.

>> Then my original message was incorrect.

> Don't worry, we all make mistakes.


Even _I_... =)
=========================cut here=============================

There should be one blank line between every level of quotation. At
least I find it difficult to distinguish between quotation levels if
there are no blank lines.

The links for messages and e-mail get snipped?


They don't *have* to, but they are allowed to. The way you're quoting
now is completely OK.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Nov 14 '05 #20

P: n/a

In article <cm**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes:

There should be one blank line between every level of quotation.


The Usenet Best Practices draft recommends otherwise (following a
similar recommendation from Son of 1036), on the grounds that those
blank lines interfere with reader features to "skip to the end of
quoted text" - a facility introduced in rn, I believe, and thus of
long standing.

UBP recommends that even empty lines in quoted text begin with the
quote-marker character (usually ">").

--
Michael Wojcik mi************@microfocus.com

He described a situation where a man is there to feed a dog and the dog is
there to keep the man from touching the equipment. -- Anthony F. Giombetti
Nov 14 '05 #21

P: n/a
Michael Wojcik <mw*****@newsguy.com> scribbled the following:
In article <cm**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes:
There should be one blank line between every level of quotation.
The Usenet Best Practices draft recommends otherwise (following a
similar recommendation from Son of 1036), on the grounds that those
blank lines interfere with reader features to "skip to the end of
quoted text" - a facility introduced in rn, I believe, and thus of
long standing. UBP recommends that even empty lines in quoted text begin with the
quote-marker character (usually ">").


That may well be, but as I said, if there are no blank lines between
levels of quotation, I find it difficult to distinguish between the
levels. Particularly if someone adds very short comments between very
long quotes, those comments appear as part of the quotes to my eyes.
The Usenet Best Practices draft can recommend what it pleases, but it
can't and won't change how my brain works at a non-conscious level.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"To doo bee doo bee doo."
- Frank Sinatra
Nov 14 '05 #22

P: n/a
Joona I Palaste wrote:

That may well be, but as I said, if there are no blank lines between
levels of quotation, I find it difficult to distinguish between the
levels. Particularly if someone adds very short comments between very
long quotes, those comments appear as part of the quotes to my eyes.
The Usenet Best Practices draft can recommend what it pleases, but it
can't and won't change how my brain works at a non-conscious level.


Just to make my voice heard, I agree with Joona.

--
Thomas.
Nov 14 '05 #23

P: n/a
In <cm*********@news3.newsguy.com> mw*****@newsguy.com (Michael Wojcik) writes:

In article <cm**********@oravannahka.helsinki.fi>, Joona I Palaste <pa*****@cc.helsinki.fi> writes:

There should be one blank line between every level of quotation.


The Usenet Best Practices draft recommends otherwise (following a
similar recommendation from Son of 1036), on the grounds that those
blank lines interfere with reader features to "skip to the end of
quoted text" - a facility introduced in rn, I believe, and thus of
long standing.

UBP recommends that even empty lines in quoted text begin with the
quote-marker character (usually ">").


Agreed, but they still do count as logically blank lines, whose only
purpose is improving the text readability.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union
Nov 14 '05 #24

P: n/a

In article <2v*************@uni-berlin.de>, Thomas Stegen <th***********@gmail.com> writes:
Joona I Palaste wrote:

That may well be, but as I said, if there are no blank lines between
levels of quotation, I find it difficult to distinguish between the
levels. Particularly if someone adds very short comments between very
long quotes, those comments appear as part of the quotes to my eyes.
The Usenet Best Practices draft can recommend what it pleases, but it
can't and won't change how my brain works at a non-conscious level.


Just to make my voice heard, I agree with Joona.


"Usenet Best Practices" is open for comment. The IETF commenting
process is well documented; see www.ietf.org. Those who care about
this sort of thing might wish to investigate it, since that would be
the ideal way to affect any RFC that develops from this draft.

Personally, I find lines containing only a quote marker (or even
multiple levels of quote markers) are adequate as vertical white-
space for my reading, which is why UBP's recommendations don't worry
me. On the other hand, since I haven't used "skip quoted material"
in recent years (I'm not even sure if xrn provides it, come to think
of it), I don't have any great affection for this recommendation,
either. I was just noting what UBP says, since it has some chance of
becoming a standard (or, at any rate, an endorsed recommendation).

--
Michael Wojcik mi************@microfocus.com

Reversible CA's are -automorphisms- on shift spaces. It is a notorious
fact in symbolic dynamics that describing such things on a shift of finite
type are -fiendishly- difficult. -- Chris Hillman
Nov 14 '05 #25

P: n/a
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41****************@news.individual.net...
ra***********@gmail.com (ranjeet) wrote:
pr****************@yahoo.com (Pravesh) wrote in message news:<e5**************************@posting.google. com>...
is there a way to get current system time in milliseconds...
which functions and headers??


Yes, there is Fucntion to compute/get time of the specified fuction.


Not in ISO C, there isn't.
(How much fucntion is taking time to execute)


That's not what he asked for.
for linux --> #include <sys/time.h>
gettimeofday

for windows --> #include <time.h>
GetTickCount is the function


Now please answer the question for the Sinclair QL. And then for my
microwave controller.


You are so obnoxiously off topic here !

Chqrlie
Nov 14 '05 #26

P: n/a

In article <cn**********@reader1.imaginet.fr>, "Charlie Gordon" <ne**@chqrlie.org> writes:
"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:41****************@news.individual.net...
ra***********@gmail.com (ranjeet) wrote:
pr****************@yahoo.com (Pravesh) wrote in message news:<e5**************************@posting.google. com>... > is there a way to get current system time in milliseconds...
> which functions and headers??

for linux ...


Now please answer the question for the Sinclair QL. And then for my
microwave controller.


You are so obnoxiously off topic here !


Richard's not off-topic. He's pointing out that Ranjeet's answer is
non-standard and not useful for some conforming C implementations.
That's entirely on-topic for comp.lang.c.

--
Michael Wojcik mi************@microfocus.com
Nov 14 '05 #27

This discussion thread is closed

Replies have been disabled for this discussion.