f



Getting time in milliseconds

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

thanks
pravesh
0
11/8/2004 11:32:47 PM
comp.lang.c 30657 articles. 5 followers. spinoza1111 (3246) is leader. Post Follow

26 Replies
475 Views

Similar Articles

[PageSpeed] 20

"Pravesh" <praveshsubramanian@yahoo.com> wrote in message
news:e5a50c3b.0411081532.5ad3177f@posting.google.com...
> 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


0
mkwahler (3821)
11/9/2004 12:33:05 AM
> > 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


0
beckjensen (317)
11/9/2004 1:34:34 AM
"Merrill & Michele" <beckjensen@comcast.net> wrote in message
news:er2dnQ6uNc5ygw3cRVn-sA@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


0
mkwahler (3821)
11/9/2004 2:43:29 AM
On Mon, 8 Nov 2004 19:34:34 -0600, "Merrill & Michele"
<beckjensen@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/~ajo/docs/FAQ-acllc.html
0
jackklein (3930)
11/9/2004 2:57:24 AM
> > > > 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;
}


0
beckjensen (317)
11/9/2004 4:18:21 AM
praveshsubramanian@yahoo.com (Pravesh) wrote in message news:<e5a50c3b.0411081532.5ad3177f@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.
0
skarpio (196)
11/9/2004 4:22:02 AM
Jack Klein wrote:

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

And then divide the result by 1000000.


Christian

0
11/9/2004 7:29:42 AM
praveshsubramanian@yahoo.com (Pravesh) wrote in message news:<e5a50c3b.0411081532.5ad3177f@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
0
11/9/2004 8:17:51 AM
Merrill & Michele <beckjensen@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  ___  Jens.Toerring@physik.fu-berlin.de
   \__________________________  http://www.toerring.de
0
11/9/2004 9:08:51 AM
ranjeet.gupta@gmail.com (ranjeet) wrote:

> praveshsubramanian@yahoo.com (Pravesh) wrote in message news:<e5a50c3b.0411081532.5ad3177f@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
0
rlb (4118)
11/9/2004 2:07:41 PM
In article <news:u--dnSh2BK332A3cRVn-2A@comcast.com>
Merrill & Michele <beckjensen@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 (40�39.22'N, 111�50.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.
0
nospam252 (1722)
11/9/2004 2:13:31 PM
> >> 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


0
beckjensen (317)
11/9/2004 2:45:24 PM
"Merrill & Michele" <beckjensen@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
0
rlb (4118)
11/9/2004 3:42:14 PM
> "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


0
beckjensen (317)
11/9/2004 5:39:13 PM
Merrill & Michele <beckjensen@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 (palaste@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"Hasta la Vista, Abie!"
   - Bart Simpson
0
palaste (2323)
11/9/2004 5:44:47 PM
"Chris Torek" <nospam@torek.net> wrote in message
news:cmqjab02r60@news2.newsguy.com...
> In article <news:u--dnSh2BK332A3cRVn-2A@comcast.com>
> Merrill & Michele <beckjensen@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. :-)

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


0
beckjensen (317)
11/9/2004 5:48:52 PM
"Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
news:cmqvmf$1hf$1@oravannahka.helsinki.fi...
> Merrill & Michele <beckjensen@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?


0
beckjensen (317)
11/9/2004 8:22:44 PM
Merrill & Michele <beckjensen@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  ___  Jens.Toerring@physik.fu-berlin.de
   \__________________________  http://www.toerring.de
0
11/9/2004 8:32:04 PM
Merrill & Michele <beckjensen@comcast.net> scribbled the following:
> "Joona I Palaste" <palaste@cc.helsinki.fi> wrote in message
> news:cmqvmf$1hf$1@oravannahka.helsinki.fi...
>> Merrill & Michele <beckjensen@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 (palaste@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."   
   - Bill Gates
0
palaste (2323)
11/10/2004 10:50:32 AM
In article <cmqvmf$1hf$1@oravannahka.helsinki.fi>, Joona I Palaste <palaste@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                  michael.wojcik@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
0
mwojcik (1879)
11/10/2004 3:31:40 PM
Michael Wojcik <mwojcik@newsguy.com> scribbled the following:
> In article <cmqvmf$1hf$1@oravannahka.helsinki.fi>, Joona I Palaste <palaste@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 (palaste@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"To doo bee doo bee doo."
   - Frank Sinatra
0
palaste (2323)
11/10/2004 3:53:47 PM
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.
0
11/10/2004 5:16:10 PM
In <cmtc8s02d28@news3.newsguy.com> mwojcik@newsguy.com (Michael Wojcik) writes:


>In article <cmqvmf$1hf$1@oravannahka.helsinki.fi>, Joona I Palaste <palaste@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: Dan.Pop@ifh.de
           Currently looking for a job in the European Union
0
Dan.Pop (3615)
11/10/2004 5:45:23 PM
In article <2vf0mqF2hhmndU1@uni-berlin.de>, Thomas Stegen <thomas.stegen@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                  michael.wojcik@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
0
mwojcik (1879)
11/11/2004 7:43:38 PM
"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:4190cee4.104078282@news.individual.net...
> ranjeet.gupta@gmail.com (ranjeet) wrote:
>
> > praveshsubramanian@yahoo.com (Pravesh) wrote in message
news:<e5a50c3b.0411081532.5ad3177f@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


0
news186 (632)
11/18/2004 3:02:58 PM
In article <cnicb5$ac6$1@reader1.imaginet.fr>, "Charlie Gordon" <news@chqrlie.org> writes:
> "Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
> news:4190cee4.104078282@news.individual.net...
> > ranjeet.gupta@gmail.com (ranjeet) wrote:
> > > praveshsubramanian@yahoo.com (Pravesh) wrote in message
> news:<e5a50c3b.0411081532.5ad3177f@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                  michael.wojcik@microfocus.com
0
mwojcik (1879)
11/19/2004 4:19:47 PM
Reply: