[13792] in Perl-Users-Digest
Perl-Users Digest, Issue: 1202 Volume: 9
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 27 23:37:49 1999
Date: Wed, 27 Oct 1999 20:37:38 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <941081858-v9-i1202@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Wed, 27 Oct 1999 Volume: 9 Number: 1202
Today's topics:
Threads in Perl 5.005_03 <dgarstan@nsw.bigpond.net.au>
Re: Threads in Perl 5.005_03 <webmaster@webdream.com>
Re: Threads in Perl 5.005_03 <gellyfish@gellyfish.com>
Re: Threads in Perl 5.005_03 (Brett W. McCoy)
Re: Threads in Perl 5.005_03 <dan@tuatha.sidhe.org>
Threads in Perl <ext-zoltan.markella@nokia.com>
Re: Threads in Perl <dan@tuatha.sidhe.org>
Re: Threads in Perl (Brett W. McCoy)
time since 1/1/1900 <r28629@email.sps.mot.com>
Re: time since 1/1/1900 (M.J.T. Guy)
Re: time since 1/1/1900 (M.J.T. Guy)
Re: time since 1/1/1900 <dan@tuatha.sidhe.org>
Re: time since 1/1/1900 (Bill Dugan)
Re: time since 1/1/1900 (Martien Verbruggen)
Re: time since 1/1/1900 <lr@hpl.hp.com>
Re: time since 1/1/1900 <r28629@email.sps.mot.com>
Re: time since 1/1/1900 <lr@hpl.hp.com>
Re: time since 1/1/1900 (Craig Berry)
Re: time since 1/1/1900 (Martien Verbruggen)
Re: time since 1/1/1900 (Martien Verbruggen)
Re: time since 1/1/1900 <marshalc@americasm01.nt.com>
To All POSIX::strftime Gurus! <spynn@nortelnetworks.com>
Re: TokenParser (Leon Brocard)
try this: <koenig@privat.toplink.de>
Re: try this: <gellyfish@gellyfish.com>
Re: try this: <r28629@email.sps.mot.com>
Trying to understand lists of lists (Steve Harvey)
Re: Trying to understand lists of lists (Bart Lateur)
Re: Trying to understand lists of lists <lr@hpl.hp.com>
Re: Trying to understand lists of lists <rootbeer@redcat.com>
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 26 Oct 1999 23:00:51 +1000
From: "Douglas Garstang" <dgarstan@nsw.bigpond.net.au>
Subject: Threads in Perl 5.005_03
Message-Id: <7v48q1$chs$1@m2.c2.telstra-mm.net.au>
From what I've been reading, Threads are available in perl 5.005_03.
Well.... unless I'm doing something wrong, therey aren't on mine!
No 'perldoc Thread', 'perldoc Threads', 'use Thread', 'use Threads' etc.
The RedHat 6.1 implementation of perl 5.005_03 isn't broken is it?
------------------------------
Date: Wed, 27 Oct 1999 15:59:00 GMT
From: "Craig Vincent" <webmaster@webdream.com>
Subject: Re: Threads in Perl 5.005_03
Message-Id: <8jFR3.10$bC3.212@198.235.216.4>
Douglas Garstang <dgarstan@nsw.bigpond.net.au> wrote in message
news:7v48q1$chs$1@m2.c2.telstra-mm.net.au...
> From what I've been reading, Threads are available in perl 5.005_03.
>
> Well.... unless I'm doing something wrong, therey aren't on mine!
>
> No 'perldoc Thread', 'perldoc Threads', 'use Thread', 'use Threads' etc.
>
> The RedHat 6.1 implementation of perl 5.005_03 isn't broken is it?
>
Theads in Perl is by default left out of the compilation.
You'll need to download the source and recompile Perl specifying you want
threads in there.
Sincerely,
Craig Vincent
------------------------------
Date: 26 Oct 1999 16:16:44 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: Threads in Perl 5.005_03
Message-Id: <3815c5dc_2@newsread3.dircon.co.uk>
Douglas Garstang <dgarstan@nsw.bigpond.net.au> wrote:
> From what I've been reading, Threads are available in perl 5.005_03.
>
> Well.... unless I'm doing something wrong, therey aren't on mine!
>
> No 'perldoc Thread', 'perldoc Threads', 'use Thread', 'use Threads' etc.
>
> The RedHat 6.1 implementation of perl 5.005_03 isn't broken is it?
>
It is unlikely that Threads have been configured in unless you compiled
the Perl and answered yes when asked - as threads are considered an
experimental feature Red hat have sensibly not put it in the their
precompiled Perl.
So answer is compile perl yourself.
/J\
--
"Killing myself is the last thing I'd ever do" - Homer Simpson
------------------------------
Date: Tue, 26 Oct 1999 13:45:00 GMT
From: bmccoy@foiservices.com (Brett W. McCoy)
Subject: Re: Threads in Perl 5.005_03
Message-Id: <slrn81bcbs.3ef.bmccoy@moebius.foiservices.com>
Also Sprach Douglas Garstang <dgarstan@nsw.bigpond.net.au>:
>From what I've been reading, Threads are available in perl 5.005_03.
>
>Well.... unless I'm doing something wrong, therey aren't on mine!
>
>No 'perldoc Thread', 'perldoc Threads', 'use Thread', 'use Threads' etc.
>
>The RedHat 6.1 implementation of perl 5.005_03 isn't broken is it?
Must be -- I'm running Perl 5.005_2 on my office server, which has Red Hat
5.2, and it has the Thread module. However, I installed Perl via tarball
rather than by RPM. I also have 5.005_03 on my Linux box at home, also
using RH 5.2, and it also has the Thread module, but again, I built it by
hand.
--
Brett W. McCoy bmccoy@foiservices.com
Computer Operations Manager (Alpha Geek) http://www.foiservices.com
FOI Services, Inc./DIOGENES 301-975-0110
---------------------------------------------------------------------------
------------------------------
Date: Tue, 26 Oct 1999 14:01:42 GMT
From: Dan Sugalski <dan@tuatha.sidhe.org>
Subject: Re: Threads in Perl 5.005_03
Message-Id: <aviR3.2073$cP2.7571@news.rdc1.ct.home.com>
In comp.lang.perl.misc Douglas Garstang <dgarstan@nsw.bigpond.net.au> wrote:
> From what I've been reading, Threads are available in perl 5.005_03.
> Well.... unless I'm doing something wrong, therey aren't on mine!
> No 'perldoc Thread', 'perldoc Threads', 'use Thread', 'use Threads' etc.
> The RedHat 6.1 implementation of perl 5.005_03 isn't broken is it?
Nope. You must explicitly build perl with threads--if you don't the thread
module isn't installed and isn't available. (Or installable later, for
that matter) A threaded build isn't standard, both because it's still
buggy and because you take a speed hit even running unthreaded.
If you want to play with threaded perl you'll need to fetch the source and
rebuild it with threads enabled.
Dan
------------------------------
Date: Mon, 25 Oct 1999 17:07:01 +0300
From: "Zoltan Markella" <ext-zoltan.markella@nokia.com>
Subject: Threads in Perl
Message-Id: <7v1btn$niv$1@netnews2.ntc.nokia.com>
Hi!
Does anyone have experience with threads in Perl? I need some help.
If you feel that you could help me, please contact me!
Thanks,
Zoltan Markella
ext-zoltan.markella@nokia.com
------------------------------
Date: Mon, 25 Oct 1999 17:06:10 GMT
From: Dan Sugalski <dan@tuatha.sidhe.org>
Subject: Re: Threads in Perl
Message-Id: <660R3.1834$cP2.5593@news.rdc1.ct.home.com>
Zoltan Markella <ext-zoltan.markella@nokia.com> wrote:
> Hi!
> Does anyone have experience with threads in Perl? I need some help.
> If you feel that you could help me, please contact me!
Perhaps if you posted your problem you might get some help? Couple of
general things:
1) Make sure you're running the latest released version of perl (5.005_03)
2) Make sure you're running the latest version of your OS
3) If you're on linux, make sure you're running the latest version of the
pthread library.
Dan
------------------------------
Date: Mon, 25 Oct 1999 14:57:36 GMT
From: bmccoy@foiservices.com (Brett W. McCoy)
Subject: Re: Threads in Perl
Message-Id: <slrn818s7u.u3d.bmccoy@moebius.foiservices.com>
Also Sprach Zoltan Markella <ext-zoltan.markella@nokia.com>:
>Does anyone have experience with threads in Perl? I need some help.
>If you feel that you could help me, please contact me!
Have you looked at the documentation for the Thread module?
--
Brett W. McCoy bmccoy@foiservices.com
Computer Operations Manager (Alpha Geek) http://www.foiservices.com
FOI Services, Inc./DIOGENES 301-975-0110
---------------------------------------------------------------------------
------------------------------
Date: Mon, 25 Oct 1999 13:46:30 -0500
From: Tk Soh <r28629@email.sps.mot.com>
Subject: time since 1/1/1900
Message-Id: <3814A586.3D6E4D10@email.sps.mot.com>
Hi there,
We have systems that give out date-time in number of seconds since
1/1/1900 00:00:00, and I need to convert them to normal date and time
format. I manage to do it by subtracting the number of seconds at
1/1/1970 since 1/1/1900, then get the date using localtime().
# -- sample of my code --
# number of seconds at 1970/1/1 0:00:00, since 1/1/1900
$opoch_start = (70*365 + 18) * 24 * 3600;
$time_since_1900 -= $opoch_start; # offset from epoch time
print "date is ", scalar gmtime $time_since_1900;
__END__
But there got to be a better way, right? Anybody?
-TK
------------------------------
Date: 27 Oct 1999 16:31:32 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: time since 1/1/1900
Message-Id: <7v79d4$ept$1@pegasus.csx.cam.ac.uk>
Larry Rosler <lr@hpl.hp.com> wrote:
>
>Here the loss of bits seems to occur after 56. But that is misleading,
>because they are all low-order zeros. The following test is definitive:
It can't possibly be definitive, since it gives the wrong answer. :-)
>% perl -e 'printf "$_ -> %.20f\n", 1 + 2**-$_ for 48 .. 55'
>48 -> 1.00000000000000360000
>49 -> 1.00000000000000180000
>50 -> 1.00000000000000090000
>51 -> 1.00000000000000040000
>52 -> 1.00000000000000020000
>53 -> 1.00000000000000000000
>54 -> 1.00000000000000000000
>55 -> 1.00000000000000000000
You're still at the mercy of the errors in the floating point conversion.
Integers are much safer, and demonstrate the correct answer (which,
as every schoolboy knows, is 53 [*] ):
% perl -we 'printf "$_ %.0f\n", 2**$_-1 for (48..54)'
48 281474976710655
49 562949953421311
50 1125899906842623
51 2251799813685247
52 4503599627370495
53 9007199254740991
54 18014398509481984
We observe that 2**53-1 is stored exactly, but 2**54-1 is not.
[*] Discovering how IEEE manages to store 53 bit integers exactly in
a 52 bit mantissa is left as an exercise for the reader.
Mike Guy
------------------------------
Date: 27 Oct 1999 16:34:02 GMT
From: mjtg@cus.cam.ac.uk (M.J.T. Guy)
Subject: Re: time since 1/1/1900
Message-Id: <7v79hq$esd$1@pegasus.csx.cam.ac.uk>
In article <38168709.10206227@nntp.ix.netcom.com>,
Bill Dugan <wkdugan@ix.netcom.com> wrote:
>On Mon, 25 Oct 1999 23:10:31 -0700, Larry Rosler <lr@hpl.hp.com>
>wrote:
>
>>I assume your second 'signed' should be 'unsigned'. But I don't
>>understand your concern with this limit of 32 bits. Because perl's
>>internal representation is double-precision, it can store integers of 52
>>bits without loss of significance.
>
>Is that guaranteed on all platforms, or does perl use whatever is
>provided by the native double precision format of the hardware?
You get whatever the underlying C doubles provide. On almost all
modern (and even quite old) platforms, the arithmetic conforms to IEEE,
so you get 53 bits.
Mike Guy
------------------------------
Date: Wed, 27 Oct 1999 13:30:03 GMT
From: Dan Sugalski <dan@tuatha.sidhe.org>
Subject: Re: time since 1/1/1900
Message-Id: <v7DR3.28$uI3.269@news.rdc1.ct.home.com>
Bill Dugan <wkdugan@ix.netcom.com> wrote:
> On Mon, 25 Oct 1999 23:10:31 -0700, Larry Rosler <lr@hpl.hp.com>
> wrote:
>>I assume your second 'signed' should be 'unsigned'. But I don't
>>understand your concern with this limit of 32 bits. Because perl's
>>internal representation is double-precision, it can store integers of 52
>>bits without loss of significance.
> Is that guaranteed on all platforms, or does perl use whatever is
> provided by the native double precision format of the hardware?
It uses whatever precision a C double is on your hardware. A double had
best have more bits of precision than an integer, or lots of perl (through
5.005_0x) will give you wacky math results.
At this point most doubles will get you 52 or 53 bits of precision, though
this is sort of platform-dependent. And if that's not enough, 5.6 sill
have long double support built in if you want it. (It's a build-time
option)
Dan
------------------------------
Date: Wed, 27 Oct 1999 06:53:33 GMT
From: wkdugan@ix.netcom.com (Bill Dugan)
Subject: Re: time since 1/1/1900
Message-Id: <38168709.10206227@nntp.ix.netcom.com>
On Mon, 25 Oct 1999 23:10:31 -0700, Larry Rosler <lr@hpl.hp.com>
wrote:
>I assume your second 'signed' should be 'unsigned'. But I don't
>understand your concern with this limit of 32 bits. Because perl's
>internal representation is double-precision, it can store integers of 52
>bits without loss of significance.
Is that guaranteed on all platforms, or does perl use whatever is
provided by the native double precision format of the hardware?
------------------------------
Date: Wed, 27 Oct 1999 00:53:49 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: time since 1/1/1900
Message-Id: <x2sR3.147$qU2.3502@nsw.nnrp.telstra.net>
On Mon, 25 Oct 1999 23:10:31 -0700,
Larry Rosler <lr@hpl.hp.com> wrote:
> In article <mx6R3.355$8F2.4260@nsw.nnrp.telstra.net> on Tue, 26 Oct 1999
> 00:24:50 GMT, Martien Verbruggen <mgjv@comdyn.com.au> says...
> > On Mon, 25 Oct 1999 13:46:30 -0500,
> > Tk Soh <r28629@email.sps.mot.com> wrote:
> > > We have systems that give out date-time in number of seconds since
> > > 1/1/1900 00:00:00, and I need to convert them to normal date and time
> >
> > Seconds since 1900? That doesn't fit in a normal signed integer. It'll
> > fit in a signed one, but you're still asking for trouble :)
>
> I assume your second 'signed' should be 'unsigned'. But I don't
> understand your concern with this limit of 32 bits. Because perl's
> internal representation is double-precision, it can store integers of 52
> bits without loss of significance.
Yes, I know Perl can. I was more worried about adapting code in
general (including C code) to this odd representation without
considering this.
Martien
--
Martien Verbruggen |
Interactive Media Division | Never hire a poor lawyer. Never buy
Commercial Dynamics Pty. Ltd. | from a rich salesperson.
NSW, Australia |
------------------------------
Date: Tue, 26 Oct 1999 15:13:20 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: time since 1/1/1900
Message-Id: <MPG.127fc75e60d9661e98a133@nntp.hpl.hp.com>
In article <38161DD1.2EF63DB@email.sps.mot.com> on Tue, 26 Oct 1999
16:32:01 -0500, Tk Soh <r28629@email.sps.mot.com> says...
> Larry Rosler wrote:
...
> > ... Because perl's
> > internal representation is double-precision, it can store integers of 52
> > bits without loss of significance.
>
> 52 or 49? is this correct?
>
> % perl -e 'print "$_ -> ${\(2**$_)}\n" for (48..53)'
> 48 -> 281474976710656
> 49 -> 562949953421312
> 50 -> 1.12589990684262e+15
> 51 -> 2.25179981368525e+15
> 52 -> 4.5035996273705e+15
> 53 -> 9.00719925474099e+15
It is not correct. What you are seeing is a result of what 'print'
chooses to do, not what the internal representation is.
% perl -e 'printf "$_ -> %.0f\n", 2**$_ for 48 .. 60'
48 -> 281474976710656
49 -> 562949953421312
50 -> 1125899906842624
51 -> 2251799813685248
52 -> 4503599627370496
53 -> 9007199254740992
54 -> 18014398509481984
55 -> 36028797018963968
56 -> 72057594037927936
57 -> 144115188075855870
58 -> 288230376151711740
59 -> 576460752303423490
60 -> 1152921504606847000
Here the loss of bits seems to occur after 56. But that is misleading,
because they are all low-order zeros. The following test is definitive:
% perl -e 'printf "$_ -> %.20f\n", 1 + 2**-$_ for 48 .. 55'
48 -> 1.00000000000000360000
49 -> 1.00000000000000180000
50 -> 1.00000000000000090000
51 -> 1.00000000000000040000
52 -> 1.00000000000000020000
53 -> 1.00000000000000000000
54 -> 1.00000000000000000000
55 -> 1.00000000000000000000
Just as I said, 52 bits!
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Tue, 26 Oct 1999 16:32:01 -0500
From: Tk Soh <r28629@email.sps.mot.com>
Subject: Re: time since 1/1/1900
Message-Id: <38161DD1.2EF63DB@email.sps.mot.com>
Larry Rosler wrote:
>
> In article <mx6R3.355$8F2.4260@nsw.nnrp.telstra.net> on Tue, 26 Oct 1999
> 00:24:50 GMT, Martien Verbruggen <mgjv@comdyn.com.au> says...
> > On Mon, 25 Oct 1999 13:46:30 -0500,
> > Tk Soh <r28629@email.sps.mot.com> wrote:
> > > We have systems that give out date-time in number of seconds since
> > > 1/1/1900 00:00:00, and I need to convert them to normal date and time
> >
> > Seconds since 1900? That doesn't fit in a normal signed integer. It'll
> > fit in a signed one, but you're still asking for trouble :)
>
> I assume your second 'signed' should be 'unsigned'. But I don't
> understand your concern with this limit of 32 bits. Because perl's
> internal representation is double-precision, it can store integers of 52
> bits without loss of significance.
52 or 49? is this correct?
% perl -e 'print "$_ -> ${\(2**$_)}\n" for (48..53)'
48 -> 281474976710656
49 -> 562949953421312
50 -> 1.12589990684262e+15
51 -> 2.25179981368525e+15
52 -> 4.5035996273705e+15
53 -> 9.00719925474099e+15
This is perl, version 5.005_01 built for sun4-solaris
> It is. It might be clearer if written as:
>
> $opoch_start = ((1970 - 1900) * 365 + 1 + int(1970 - 1900)/4) *
> 24 * 3600;
hmm.. would be helpful in case my vendor decide to use 1/1/1950 later.
-TK
------------------------------
Date: Mon, 25 Oct 1999 23:10:31 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: time since 1/1/1900
Message-Id: <MPG.127ee5b6c5886b0c98a128@nntp.hpl.hp.com>
In article <mx6R3.355$8F2.4260@nsw.nnrp.telstra.net> on Tue, 26 Oct 1999
00:24:50 GMT, Martien Verbruggen <mgjv@comdyn.com.au> says...
> On Mon, 25 Oct 1999 13:46:30 -0500,
> Tk Soh <r28629@email.sps.mot.com> wrote:
> > We have systems that give out date-time in number of seconds since
> > 1/1/1900 00:00:00, and I need to convert them to normal date and time
>
> Seconds since 1900? That doesn't fit in a normal signed integer. It'll
> fit in a signed one, but you're still asking for trouble :)
I assume your second 'signed' should be 'unsigned'. But I don't
understand your concern with this limit of 32 bits. Because perl's
internal representation is double-precision, it can store integers of 52
bits without loss of significance.
> > format. I manage to do it by subtracting the number of seconds at
> > 1/1/1970 since 1/1/1900, then get the date using localtime().
> >
> > # number of seconds at 1970/1/1 0:00:00, since 1/1/1900
> > $opoch_start = (70*365 + 18) * 24 * 3600;
>
> I'll assume that that number is correct :)
It is. It might be clearer if written as:
$opoch_start = ((1970 - 1900) * 365 + 1 + int(1970 - 1900)/4) *
24 * 3600;
...
> Well, I'd probably use something like Date::Calc or one of the other
> modules on CPAN, and I probably would avoid using the number of
> seconds since 1900, because it is larger than 2<<31 - 1.
See above. In two words, so what?
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Mon, 25 Oct 1999 23:52:46 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: time since 1/1/1900
Message-Id: <s19raep4gbb20@corp.supernews.com>
Marshall Culpepper (marshalc@americasm01.nt.com) wrote:
: the perl function 'time()' returns the time since 1900 so
: print "date is ", scalar gmtime time;
: is effectively the same.
Huh? From perldoc -f time:
Returns the number of non-leap seconds since whatever time the system
considers to be the epoch (that's 00:00:00, January 1, 1904 for MacOS,
and 00:00:00 UTC, January 1, 1970 for most other systems). Suitable for
feeding to gmtime() and localtime().
Note that time() uses different bases on different systems, so if
portability is an issue, the ice is especially thin here.
--
| Craig Berry - cberry@cinenet.net
--*-- http://www.cinenet.net/users/cberry/home.html
| "They do not preach that their God will rouse them
a little before the nuts work loose." - Kipling
------------------------------
Date: Tue, 26 Oct 1999 00:07:57 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: time since 1/1/1900
Message-Id: <xh6R3.349$8F2.4029@nsw.nnrp.telstra.net>
On Mon, 25 Oct 1999 15:49:44 -0500,
Marshall Culpepper <marshalc@americasm01.nt.com> wrote:
> Tk Soh wrote:
>
> > Hi there,
> >
> > We have systems that give out date-time in number of seconds since
> > 1/1/1900 00:00:00, and I need to convert them to normal date and time
> > format. I manage to do it by subtracting the number of seconds at
> > 1/1/1970 since 1/1/1900, then get the date using localtime().
> >
> > # -- sample of my code --
> >
> > # number of seconds at 1970/1/1 0:00:00, since 1/1/1900
> > $opoch_start = (70*365 + 18) * 24 * 3600;
> >
> > $time_since_1900 -= $opoch_start; # offset from epoch time
> >
> > print "date is ", scalar gmtime $time_since_1900;
> >
> > __END__
> >
> > But there got to be a better way, right? Anybody?
>
> the perl function 'time()' returns the time since 1900 so
Euhmm, no, it doesn't.
# perldoc -f time
=item time
Returns the number of non-leap seconds since whatever time the system
considers to be the epoch (that's 00:00:00, January 1, 1904 for MacOS,
and 00:00:00 UTC, January 1, 1970 for most other systems).
Suitable for feeding to C<gmtime()> and C<localtime()>.
What you probably mean is that the year that localtime returns is the
current year - 1900.
Martien
--
Martien Verbruggen |
Interactive Media Division | Freudian slip: when you say one thing
Commercial Dynamics Pty. Ltd. | but mean your mother.
NSW, Australia |
------------------------------
Date: Tue, 26 Oct 1999 00:24:50 GMT
From: mgjv@comdyn.com.au (Martien Verbruggen)
Subject: Re: time since 1/1/1900
Message-Id: <mx6R3.355$8F2.4260@nsw.nnrp.telstra.net>
On Mon, 25 Oct 1999 13:46:30 -0500,
Tk Soh <r28629@email.sps.mot.com> wrote:
> Hi there,
>
> We have systems that give out date-time in number of seconds since
> 1/1/1900 00:00:00, and I need to convert them to normal date and time
Seconds since 1900? That doesn't fit in a normal signed integer. It'll
fit in a signed one, but you're still asking for trouble :)
> format. I manage to do it by subtracting the number of seconds at
> 1/1/1970 since 1/1/1900, then get the date using localtime().
>
> # number of seconds at 1970/1/1 0:00:00, since 1/1/1900
> $opoch_start = (70*365 + 18) * 24 * 3600;
I'll assume that that number is correct :)
> $time_since_1900 -= $opoch_start; # offset from epoch time
Where is $time_since_1900 originally set? Or is it 0 at this point?
> print "date is ", scalar gmtime $time_since_1900;
If $time_since_1900 was 0, then
gmtime -$opochtime;
will also work. But for me that tells me:
Fri Dec 13 20:45:52 1901
> But there got to be a better way, right? Anybody?
Well, I'd probably use something like Date::Calc or one of the other
modules on CPAN, and I probably would avoid using the number of
seconds since 1900, because it is larger than 2<<31 - 1.
Martien
--
Martien Verbruggen |
Interactive Media Division | Freudian slip: when you say one thing
Commercial Dynamics Pty. Ltd. | but mean your mother.
NSW, Australia |
------------------------------
Date: Mon, 25 Oct 1999 15:49:44 -0500
From: Marshall Culpepper <marshalc@americasm01.nt.com>
Subject: Re: time since 1/1/1900
Message-Id: <3814C267.DE76DCBF@americasm01.nt.com>
Tk Soh wrote:
> Hi there,
>
> We have systems that give out date-time in number of seconds since
> 1/1/1900 00:00:00, and I need to convert them to normal date and time
> format. I manage to do it by subtracting the number of seconds at
> 1/1/1970 since 1/1/1900, then get the date using localtime().
>
> # -- sample of my code --
>
> # number of seconds at 1970/1/1 0:00:00, since 1/1/1900
> $opoch_start = (70*365 + 18) * 24 * 3600;
>
> $time_since_1900 -= $opoch_start; # offset from epoch time
>
> print "date is ", scalar gmtime $time_since_1900;
>
> __END__
>
> But there got to be a better way, right? Anybody?
the perl function 'time()' returns the time since 1900 so
print "date is ", scalar gmtime time;
is effectively the same.
~Marshall
--
Kids in the backseat cause accidents, Accidents in the back seat cause kids.
------------------------------
Date: Tue, 26 Oct 1999 16:53:50 -0400
From: Scott Pynn <spynn@nortelnetworks.com>
Subject: To All POSIX::strftime Gurus!
Message-Id: <381614DE.80DB89B1@nortelnetworks.com>
Hi all,
I'm having trouble printing out the week number from a call to
POSIX::strftime.
It seems that the following line
print POSIX::strftime("%YW%U -- %H:%M:%S, %d %h %Y\n", $s, $m,
$h, $d, $mo, $y, 0, 0, 0);
SHOULD print out
1999W36 -- 11:17:29, 08 Sep 1999
but it instead displays
1999W01 -- 11:17:29, 08 Sep 1999
That is, I'm expecting "36", but actually get "01".
What am I missing??
Thanks in advance!
------------------------------------------------------------------------
Scott Pynn
Nortel Networks
Ottawa, ON
Canada
------------------------------
Date: 26 Oct 1999 10:17:59 GMT
From: acme@tigger.netcraft.com (Leon Brocard)
Subject: Re: TokenParser
Message-Id: <slrn81av2s.1lk.acme@tigger.netcraft.com>
Howard typed out randomly:
> How can I use parse a $content without saving it on disk first?
Hmmm. How about you check the documentation for HTML::TokeParser?
It says:
$p = HTML::TokeParser->new( $file_or_doc );
The object constructor argument is either a file name,
a file handle object, or the complete document to be
parsed.
If the argument is a plain scalar, then it is taken as
the name of a file to be opened and parsed. If the
file can't be opened for reading, then the constructor
will return an undefined value and $! will tell you
why it failed.
If the argument is a reference to a plain scalar, then
this scalar is taken to be the document to parse.
So something like '$p = HTML::TokeParser->new(\$content);'
will do what you want.
HTH, Leon
--
Leon Brocard................................http://bath.pm.org/
leon@netcraft.com........................http://www.astray.com/
... Don't look back, the lemmings are gaining on you
------------------------------
Date: Wed, 27 Oct 1999 14:22:06 +0200
From: Hartmut =?iso-8859-1?Q?K=F6nig?= <koenig@privat.toplink.de>
Subject: try this:
Message-Id: <3816EE6D.85972ED8@privat.toplink.de>
$#arrayname
--
Wem das Wasser bis zum Halse steht, der darf den Kopf
nicht haengen lassen.
Joerg Schoenborn (General und Politiker)
---
Hartmut König
------------------------------
Date: 27 Oct 1999 16:08:03 +0100
From: Jonathan Stowe <gellyfish@gellyfish.com>
Subject: Re: try this:
Message-Id: <38171553_1@newsread3.dircon.co.uk>
Hartmut König <koenig@privat.toplink.de> wrote:
> $#arrayname
>
Its still wrong even when you are being cryptic
scalar @arrayname;
/J\
--
"Nourishes at the root and penetrates right to the tip" - Pantene
Advertisement
------------------------------
Date: Wed, 27 Oct 1999 09:14:03 -0400
From: TK Sohj <r28629@email.sps.mot.com>
Subject: Re: try this:
Message-Id: <3816FA9B.B967878@email.sps.mot.com>
Hartmut König wrote:
>
> $#arrayname
>
> --
> Wem das Wasser bis zum Halse steht, der darf den Kopf
> nicht haengen lassen.
> Joerg Schoenborn (General und Politiker)
> ---
> Hartmut König
try what? German to English translation?
-TK
------------------------------
Date: 26 Oct 1999 20:15:24 GMT
From: steveharvey@geocities.com (Steve Harvey)
Subject: Trying to understand lists of lists
Message-Id: <slrn81c2ur.1bo.steveharvey@itc001472.usitc.gov>
I just wrote a program which uses multidimensional arrays to track
information where I don't know the size of the array ahead of time
nor do I know which members of the array will be used. To elucidate,
a code sample:
($month, $day, $year, $status) = unpack("A2 x1 A2 x1 A4 x1 A7", $_);
++$total{$month, $day, $year};
if ($status eq "SUCCESS") {
++$success{$month, $day, $year}
}
elsif ($status eq "FAILURE") {
++$failure{$month, $day, $year}
}
This is from a subroutine which parses a transaction log where each
entry logs a success or failure. I am tracking how many total transactions
occur on each day, as well as how many successes and failures. I am assigning
the array indices on the fly because there is no guarantee that a given
month/day will contain transactions.
In any case, the code above works fine, but when I was reading about
arrays in perldoc and the camel book, it explained that the syntax I used
above was known as "multidimensional associative array emulation syntax"
(wow I like how that rolls off the tongue), and is mostly provided for
backwards compatibility, and that a better way to do thing is with
lists-of-lists (which I assume means a list where the list members are
pointers to other lists). I've never used these features before and am
having a hard time understanding their usefullness from the examples
given.
Could somebody give me an idea of how the above code could be written to
better take advantage of "The Perl way"?
Thanks,
Steve
------------------------------
Date: Wed, 27 Oct 1999 11:00:03 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Trying to understand lists of lists
Message-Id: <381ada37.3147532@news.skynet.be>
Steve Harvey wrote:
>($month, $day, $year, $status) = unpack("A2 x1 A2 x1 A4 x1 A7", $_);
>++$total{$month, $day, $year};
>if ($status eq "SUCCESS") {
> ++$success{$month, $day, $year}
>}
>elsif ($status eq "FAILURE") {
> ++$failure{$month, $day, $year}
>}
...
>Could somebody give me an idea of how the above code could be written to
>better take advantage of "The Perl way"?
Sorry to ignore your actual question but: first you're unpacking a
string into multiple variables, and then you're reconcatenating them
again, in order to get a unique hash key. (True, the value of $; , by
default "\034" I think, is inserted between them.) That is a bit silly
IMO. You can just as well simply repack them:
$success{pack('A2A2A4', $month, $day, $year, $status)}++;
--
Bart.
------------------------------
Date: Tue, 26 Oct 1999 14:53:09 -0700
From: Larry Rosler <lr@hpl.hp.com>
Subject: Re: Trying to understand lists of lists
Message-Id: <MPG.127fc2a48128351c98a132@nntp.hpl.hp.com>
In article <slrn81c2ur.1bo.steveharvey@itc001472.usitc.gov> on 26 Oct
1999 20:15:24 GMT, Steve Harvey <steveharvey@geocities.com> says...
> I just wrote a program which uses multidimensional arrays to track
> information where I don't know the size of the array ahead of time
> nor do I know which members of the array will be used. To elucidate,
> a code sample:
>
> ($month, $day, $year, $status) = unpack("A2 x1 A2 x1 A4 x1 A7", $_);
> ++$total{$month, $day, $year};
> if ($status eq "SUCCESS") {
> ++$success{$month, $day, $year}
> }
> elsif ($status eq "FAILURE") {
> ++$failure{$month, $day, $year}
> }
...
> Could somebody give me an idea of how the above code could be written to
> better take advantage of "The Perl way"?
Replace the comma-separated set of keys by separate keys:
++$total{$month}{$day}{$year};
If the values of, say, $month or $day are small integers, arrays might
be better:
++$total[$month][$day]{$year};
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Tue, 26 Oct 1999 15:20:10 -0700
From: Tom Phoenix <rootbeer@redcat.com>
Subject: Re: Trying to understand lists of lists
Message-Id: <Pine.GSO.4.10.9910261517200.29843-100000@user2.teleport.com>
On 26 Oct 1999, Steve Harvey wrote:
> ++$success{$month, $day, $year}
As you said, you know this isn't a "list of lists". It's actually the
syntax we used in the bad old days when Perl didn't have lists of
(references to) lists.
You should probably use true references instead.
++$success{$month}{$day}{$year}; # maybe?
See perlref, perllol, and perldsc to get started. Good luck!
--
Tom Phoenix Perl Training and Hacking Esperanto
Randal Schwartz Case: http://www.rahul.net/jeffrey/ovs/
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>
Administrivia:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V9 Issue 1202
**************************************
