eternal time question 
Author Message
 eternal time question

Sorry for that question I remember seeing answered in past posts..

I have a log of a files-transfer activity, that looks like this:

YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 BEGIN FileName FileSize
...
YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 END
...

I want to calculate the difference between BEGIN and END time stamps, in
order to deduce the transfer rate.
In the man, I can see the strftime(format,value) function that prints a
string "date" from the number of seconds since 01/01/1970, but I can't find
the reciproquial function that would calculate that number of seconds from
the string "YYYY/MM/DD hh:mm:ss".

In the past I wrote my own function but it seems to have failed pass Y2K ;o)
or some other date, it gives me false value today compared to what {print
systime()} returns.
PS: Looking at my pityfull code, I wonder what I had wrong in what seems to
be a so simple count-down of seconds problem...
Has anyone an accurate function time("YYYY/MM/DD hh:mm:ss") at hand?

Thanks for helping.



Thu, 04 Dec 2003 06:34:49 GMT  
 eternal time question

Quote:

> Sorry for that question I remember seeing answered in past posts..

> I have a log of a files-transfer activity, that looks like this:

> YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 BEGIN FileName FileSize
> ...
> YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 END
> ...

> I want to calculate the difference between BEGIN and END time stamps, in
> order to deduce the transfer rate.

Do it like you would do i manually:

  YYYY/MM/DD  hh:mm:ss   END time
- YYYY/MM/DD  hh:mm:ss START time

Probably you don't need to control a nuclear power plant with these
calculations, so you can make some pragmatic assumptions:

a) File transfers won't take longer than one day. If both of the
   YYYY/MM/DD aren't the same, you want to add 24 hours somewhere.
b) Daylight savings time changes don't exist. Your statistic can be
   built only on workdays (like all these "professional" Excel
   statistics), so no problem whatsoever ;-)
c) Leap seconds are nothing that everyone bothers about, so why should
   you?

Regards...
                Michael

P.S.: If you have gawk, you might want to look at the mktime()
function. From `GAWK: Effective AWK Programming: A User's Guide for GNU
Awk':
|   The `mktime' function allows you to convert a textual representation
| of a date and time into a timestamp.   This makes it easy to do
| before/after comparisons of dates and times, particularly when dealing
| with date and time data coming from an external source, such as a log
| file.



Thu, 04 Dec 2003 09:03:52 GMT  
 eternal time question

Quote:

> Sorry for that question I remember seeing answered in past posts..

> I have a log of a files-transfer activity, that looks like this:

> YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 BEGIN FileName FileSize
> ...
> YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 END
> ...

> I want to calculate the difference between BEGIN and END time stamps, in
> order to deduce the transfer rate.
> In the man, I can see the strftime(format,value) function that prints a
> string "date" from the number of seconds since 01/01/1970, but I can't find
> the reciproquial function that would calculate that number of seconds from
> the string "YYYY/MM/DD hh:mm:ss".

> In the past I wrote my own function but it seems to have failed pass Y2K ;o)
> or some other date, it gives me false value today compared to what {print
> systime()} returns.
> PS: Looking at my pityfull code, I wonder what I had wrong in what seems to
> be a so simple count-down of seconds problem...
> Has anyone an accurate function time("YYYY/MM/DD hh:mm:ss") at hand?

> Thanks for helping.

Hello,

here's a small perl script, which can do this:

#!/usr/bin/perl

use HTTP::Date;

while (<DATA>) {
$utime = <DATA>;
$l = time2str($utime);
print "$l\n";

Quote:
}          

usage:
scriptname logfile

Sure this is comp.lang.awk, however times I needed something like this,
I figured out, it would be much easier using perls time2str function...

Michael Heiming



Thu, 04 Dec 2003 09:23:20 GMT  
 eternal time question


Quote:

> > Sorry for that question I remember seeing answered in past posts..

> > I have a log of a files-transfer activity, that looks like this:

> > YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 BEGIN FileName FileSize
> > ...
> > YYYY/MM/DD  hh:mm:ss 224.1.1.1  5000 END
> > ...

> > I want to calculate the difference between BEGIN and END time stamps, in
> > order to deduce the transfer rate.

> Do it like you would do i manually:

>   YYYY/MM/DD  hh:mm:ss   END time
> - YYYY/MM/DD  hh:mm:ss START time

> Probably you don't need to control a nuclear power plant with these
> calculations, so you can make some pragmatic assumptions:

> a) File transfers won't take longer than one day. If both of the
>    YYYY/MM/DD aren't the same, you want to add 24 hours somewhere.
> b) Daylight savings time changes don't exist. Your statistic can be
>    built only on workdays (like all these "professional" Excel
>    statistics), so no problem whatsoever ;-)
> c) Leap seconds are nothing that everyone bothers about, so why should
>    you?

> Regards...
> Michael

> P.S.: If you have gawk, you might want to look at the mktime()
> function. From `GAWK: Effective AWK Programming: A User's Guide for GNU
> Awk':
> |   The `mktime' function allows you to convert a textual representation
> | of a date and time into a timestamp.   This makes it easy to do
> | before/after comparisons of dates and times, particularly when dealing
> | with date and time data coming from an external source, such as a log
> | file.

Thanks a lot Michael, and shame shame shame on me,

As soon as I sent my previous message I found the source of "mktime", the
exact answer to my question at:
http://chaos.phy.ohiou.edu/~thomas/ref/info/gawk/Mktime_Function.html

Indeed my own time() function still works well, at least it gives the same
Epoch value as Robbin's, that is 7 hours ahead of strftime(), in fact I
understood I fell into the mysterious "Time Zone" trap.

So my apologies for that idiot post, forget it, or instead try to answer my
new question "why are'nt we all living on the same time zone?" ;o)

and while you search an answer, I 'll go and search for "the effective Awk
programming", and  the user's guide for goofs ;-(



Thu, 04 Dec 2003 09:22:08 GMT  
 eternal time question


Quote:

> Hello,

> here's a small perl script, which can do this:

> #!/usr/bin/perl

> use HTTP::Date;

> while (<DATA>) {
> $utime = <DATA>;
> $l = time2str($utime);
> print "$l\n";
> }

> usage:
> scriptname logfile

> Sure this is comp.lang.awk, however times I needed something like this,
> I figured out, it would be much easier using perls time2str function...

> Michael Heiming

Thanks Michael for this Perlish way.

But my problem should be solved by the mktime() function, (well as soon as I
have it because the gawk version I have (3.0) is rather old and doesn't know
that function.)

By the way why to use HTTP::Date? what relation is there with HTTP?



Thu, 04 Dec 2003 09:34:24 GMT  
 eternal time question

Quote:



> > Hello,

> > here's a small perl script, which can do this:

> > #!/usr/bin/perl

> > use HTTP::Date;

> > while (<DATA>) {
> > $utime = <DATA>;
> > $l = time2str($utime);
> > print "$l\n";
> > }

> > usage:
> > scriptname logfile

> > Sure this is comp.lang.awk, however times I needed something like this,
> > I figured out, it would be much easier using perls time2str function...

> > Michael Heiming

> Thanks Michael for this Perlish way.

> But my problem should be solved by the mktime() function, (well as soon as I
> have it because the gawk version I have (3.0) is rather old and doesn't know
> that function.)

True, shame on me, I'm using mostly gawk (3.0.5), but didn't know until
now about the mktime() function...:-(

Quote:
> By the way why to use HTTP::Date? what relation is there with HTTP?

This module provides the tim2str function. Perhaps, because it's useful
in conjunction with (httpd) log files?

Michael Heiming



Thu, 04 Dec 2003 15:07:40 GMT  
 eternal time question



Quote:

> True, shame on me, I'm using mostly gawk (3.0.5), but didn't know until
> now about the mktime() function...:-(

> > By the way why to use HTTP::Date? what relation is there with HTTP?

> This module provides the tim2str function. Perhaps, because it's useful
> in conjunction with (httpd) log files?

> Michael Heiming

Shame on you too then for forgetting the mktime() function ;o)
May be it could be worth considering some Perl 2 awk conversion of your fat
Perl' scripts ;o)
(Or wait for the p2a project to come)

We can't be alone, to be honnest when I wrote my own mktime(), I didn't even
knew of strftime(), and also wrote my own ligth version! what a shame!
But at least I could run my scripts on ancestral Motorola 68000 VME
machines.

To forget my stupid post, but keep on to date problem, I put a second
chance'question:

My function works (well?) until:
"Mon Jan 18 19:14:07 2038" (2^31 -1)
but after that, I get:
awk: warning
     Overflow in conversion of floating point number to integer

Arnold's is better (of course!) and works until:
"Sat Feb 05 22:38:15 2106" (2^32 -1)
But on the other side, mine starts down from 01/01/1970 when Arnold's starts
only at 01/01/1980, he probably made the assumption there was no time stamps
in the 70's exept made by hand...

I must figure out how he managed to have twice as much, by 2038 I'll be 79
and if alive, I bet I'll still be doing statistics on log files just for fun
then...

So my new question is: what will be done when we reach the 32 bits limit?
- set the new Epoch value to 01/01/2070 and redo from start for another 136
years?
- recompile the awk code to change the date representation to 64 bits?
- none of the above as there won't be enough oxygen left for a normal human
brain to even think of solving the 32 bits limit?

Anyone a clue ? ;o)



Thu, 04 Dec 2003 17:50:37 GMT  
 eternal time question

Quote:



> > True, shame on me, I'm using mostly gawk (3.0.5), but didn't know until
> > now about the mktime() function...:-(

> > > By the way why to use HTTP::Date? what relation is there with HTTP?

> > This module provides the tim2str function. Perhaps, because it's useful
> > in conjunction with (httpd) log files?

> > Michael Heiming

> Shame on you too then for forgetting the mktime() function ;o)
> May be it could be worth considering some Perl 2 awk conversion of your fat
> Perl' scripts ;o)

I'm just starting with perl, so sadly I can't consider my scripts as
"fat", today....:-)

- Show quoted text -

Quote:
> (Or wait for the p2a project to come)

> We can't be alone, to be honnest when I wrote my own mktime(), I didn't even
> knew of strftime(), and also wrote my own ligth version! what a shame!
> But at least I could run my scripts on ancestral Motorola 68000 VME
> machines.

> To forget my stupid post, but keep on to date problem, I put a second
> chance'question:

> My function works (well?) until:
> "Mon Jan 18 19:14:07 2038" (2^31 -1)
> but after that, I get:
> awk: warning
>      Overflow in conversion of floating point number to integer

> Arnold's is better (of course!) and works until:
> "Sat Feb 05 22:38:15 2106" (2^32 -1)
> But on the other side, mine starts down from 01/01/1970 when Arnold's starts
> only at 01/01/1980, he probably made the assumption there was no time stamps
> in the 70's exept made by hand...

> I must figure out how he managed to have twice as much, by 2038 I'll be 79
> and if alive, I bet I'll still be doing statistics on log files just for fun
> then...

> So my new question is: what will be done when we reach the 32 bits limit?
> - set the new Epoch value to 01/01/2070 and redo from start for another 136
> years?
> - recompile the awk code to change the date representation to 64 bits?
> - none of the above as there won't be enough oxygen left for a normal human
> brain to even think of solving the 32 bits limit?

> Anyone a clue ? ;o)

http://www.tru64unix.compaq.com/faqs/publications/base_doc/DOCUMENTAT...

Some vendors do have their systems ready, even if most apps use the
industrial
standard 32bit time today...:-)

Michael Heiming



Fri, 05 Dec 2003 05:36:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. ETERNAL LIFE DEVICE INVENTED

2. search order of eternal programs

3. The eternal topic (8-bit microcontrollers)

4. Eternal programming

5. eternal listbox problems

6. Bug in time.c (was Time.times problems)

7. time and scheduling (was: bug report: [ #447945 ] time.time() is not non-decreasing)

8. time zones, daylight saving time, and universal time

9. Dumb question re date/time picker

10. question on comparing date/time in AWK

 

 
Powered by phpBB® Forum Software