[31381] in Perl-Users-Digest
Perl-Users Digest, Issue: 2633 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Oct 12 18:09:45 2009
Date: Mon, 12 Oct 2009 15:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 12 Oct 2009 Volume: 11 Number: 2633
Today's topics:
CFP: International Symposium on Memory Management 2010 khdev4u@yahoo.com
FAQ 8.9 How do I ask the user for a password? <brian@theperlreview.com>
Re: Help needed with tough regular expression matching <ramon@conexus.net>
Re: Help needed with tough regular expression matching <ramon@conexus.net>
Re: Help needed with tough regular expression matching <m@rtij.nl.invlalid>
Re: Help needed with tough regular expression matching <ramon@conexus.net>
Re: Help needed with tough regular expression matching <tadmc@seesig.invalid>
Re: Help needed with tough regular expression matching <ben@morrow.me.uk>
Re: Help needed with tough regular expression matching <ramon@conexus.net>
Re: Help needed with tough regular expression matching <ramon@conexus.net>
Re: regexp assistance <hjp-usenet2@hjp.at>
Re: regexp assistance <jurgenex@hotmail.com>
Re: time format +1 hour <hjp-usenet2@hjp.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 12 Oct 2009 12:14:10 -0700 (PDT)
From: khdev4u@yahoo.com
Subject: CFP: International Symposium on Memory Management 2010
Message-Id: <7bf6c3d3-48b7-4720-bbbc-bd05f049685e@j24g2000yqa.googlegroups.com>
International Symposium on Memory Management 2010
Toronto, June 5-6, 2010
http://www.cs.purdue.edu/ISMM10/
CALL FOR PAPERS
ISMM is a forum for research in memory management. Areas of interest
include
but are not limited to:
* Memory allocation and deallocation
* Garbage collection algorithms and implementations
* Compiler analyses and tools to aid memory management
* Empirical analysis of heap intensive programs
* Formal analysis and verification of heap intensive programs
* Memory system design and analysis
* Verification of memory management algorithms
* Development and evaluation of open source implementations
ISMM solicits full-length submissions covering new work on these
topics, as
well as papers presenting confirmations or refutations of important
prior
results. Surveys and comparative analyses that shed new light on
previously
published techniques are also welcome.
ORGANIZERS
General Chair: Jan Vitek, Purdue University
Program Chair: Doug Lea, State University of New York at Oswego
Program Committee:
* Hans Boehm, HP Labs
* Cliff Click, Azul Systems
* David Detlefs, Microsoft Research
* Dave Dice, Sun Microsystems
* Christine Flood, Sun Microsystems
* Daniel Frampton, Australian National University
* Samir Genaim, Complutense University of Madrid
* Richard Jones, University of Kent
* Simon Marlow, Microsoft Research
* Nick Mitchell, IBM T.J. Watson Research
* Filip Pizlo, Purdue University
* Martin Vechev, IBM T.J. Watson Research
* Adam Welc, Intel
KEY DATES
Abstracts due: February 3, 2010
Submissions due: February 9, 2010
Author response: March 9-11, 2010
Notification: March 19, 2010
Final copy: April 2, 2010
Conference: June 5-6, 2010
SUBMISSIONS
Submitted papers must be in English and formatted to print on US
Letter (8.5 x
11 inches) paper. Submissions must contain an abstract and postal and
electronic
mailing addresses for at least one contact author. All papers must be
submitted
on-line, preferably in Portable Document Format (PDF), although the
submission
system will also accept PostScript. Submissions should be no more than
10 pages
(including bibliography, excluding well marked appendices) in standard
ACM
SIGPLAN conference format: two columns, nine-point font (or larger) on
a
ten-point baseline (or larger), with columns 20pc (3.33in) wide and
54pc (9in)
tall, and a column gutter of 2pc (0.33in). Detailed formatting
guidelines along
with formatting templates or style files for LaTeX are available at
http://www.acm.org/sigs/sigplan/authorInformation.htm. Papers that
violate these
guidelines will be rejected by the program chair. Program committee
members are
not required to read appendices, and so a paper should be intelligible
without
them. All accepted papers will appear in the published proceedings.
Double-blind reviewing
Authors are anonymous to the reviewers, just as reviewers are
anonymous to the
authors. Authors must take reasonable efforts not to disclose their
identities
to reviewers: Do not give your names nor mention your institution,
research
group or project name. Where necessary for flow, a stand-in name such
as "XYZ",
may be used, with a footnote explaining that the actual name is
withheld.
Discuss your own prior work in the third person, as you would other
related
work. You may also provide reviewers with anonymous auxiliary material
such as
proofs and source code via the PC Chair (see below). Reviewers, for
their part,
will be honor-bound not to try to discover authors' identities until
their
initial reviews are complete. Authors' identities will be revealed at
a later
point in the program committee's deliberations, but will be known only
to the
program chair until that point.
Review committee
ISMM uses a separate Review Committee (RC) as part of the reviewing
process. The
RC complements the Program Committee (PC) by providing expert reviews.
The same
reviewing standards apply to the RC as for the PC. However, RC members
review
only a few papers each, and do not participate in the PC meeting. The
use of the
RC increases the breadth and depth of the reviewer pool.
Rebuttal
The rebuttal process will occur in early March 2010, and will give the
authors
opportunity to respond succinctly to factual errors in reviews, before
the
program committee meets to make its decisions. The committee may, but
need not,
respond to rebuttals or revise reviews at or after the committee
meeting.
Auxiliary Material
Authors may provide the PC Chair with a URL for upload of auxiliary
material.
The URL itself will not be seen by reviewers. The authors may
reference such
material in their paper, noting that the material has been made
available to the
PC Chair. This facility may be used by authors to provide reviewers
with useful
information beyond the scope of the submitted paper, such as technical
reports,
proofs, and source code, without disclosing the authors' identity.
Authors are
obliged to make reasonable efforts to make all auxiliary material
suitably
anonymous. Authors are reminded that reviewers are under no obligation
to read
any auxiliary material.
Papers accompanied by or based on open-source implementations are
especially
welcome. However, if the authors are primary contributors to such a
project,
they should provide source URLs separately to the Program Chair for
validation,
and not list them in the submission proper.
Proceedings
The proceedings will be published by the ACM. Authors should read the
ACM Author
Guidelines and related information. Authors of accepted papers must
guarantee
that their paper will be presented at the conference. For additional
information
please feel free to contact the Program Chair.
------------------------------
Date: Mon, 12 Oct 2009 22:00:07 GMT
From: PerlFAQ Server <brian@theperlreview.com>
Subject: FAQ 8.9 How do I ask the user for a password?
Message-Id: <HFNAm.33814$tG1.22590@newsfe22.iad>
This is an excerpt from the latest version perlfaq8.pod, which
comes with the standard Perl distribution. These postings aim to
reduce the number of repeated questions as well as allow the community
to review and update the answers. The latest version of the complete
perlfaq is at http://faq.perl.org .
--------------------------------------------------------------------
8.9: How do I ask the user for a password?
(This question has nothing to do with the web. See a different FAQ for
that.)
There's an example of this in "crypt" in perlfunc). First, you put the
terminal into "no echo" mode, then just read the password normally. You
may do this with an old-style ioctl() function, POSIX terminal control
(see POSIX or its documentation the Camel Book), or a call to the stty
program, with varying degrees of portability.
You can also do this for most systems using the Term::ReadKey module
from CPAN, which is easier to use and in theory more portable.
use Term::ReadKey;
ReadMode('noecho');
$password = ReadLine(0);
--------------------------------------------------------------------
The perlfaq-workers, a group of volunteers, maintain the perlfaq. They
are not necessarily experts in every domain where Perl might show up,
so please include as much information as possible and relevant in any
corrections. The perlfaq-workers also don't have access to every
operating system or platform, so please include relevant details for
corrections to examples that do not work on particular platforms.
Working code is greatly appreciated.
If you'd like to help maintain the perlfaq, see the details in
perlfaq.pod.
------------------------------
Date: Mon, 12 Oct 2009 11:11:34 -0700 (PDT)
From: Ramon F Herrera <ramon@conexus.net>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <7c70c62e-8ece-48db-80eb-fb6f79524bde@a32g2000yqm.googlegroups.com>
On Oct 12, 1:27=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Ramon F Herrera <ra...@conexus.net>:
>
>
>
>
>
> > (2) My future feature will be based on "quarters" instead of integers.
> > This is an instance of the most basic unit:
>
> > 4/2008
>
> > (meaning the 4th. quarter of year 2008, of course).
>
> > Therefore the notation (I don't allow spaces, btw) will look like
> > this:
>
> > 2/2000,3/2000,4/2000,1/2005,2/2005-1/2006
>
> > Which could be minimally expressed like this:
>
> > 2/2000-4/2000,1/2005-1/2006
>
> Right... so you want
>
> =A0 =A0 my $qtr =A0 =A0 =3D qr! [1234] / \d{4} =A0 =A0 =A0 =A0!x;
> =A0 =A0 my $range =A0 =3D qr! $qtr - $qtr =A0 =A0 =A0 =A0 =A0 !x;
> =A0 =A0 my $item =A0 =A0=3D qr! $qtr | $range =A0 =A0 =A0 =A0 !x;
> =A0 =A0 my $expr =A0 =A0=3D qr! $item (?: , $item )* =A0!x;
>
> Translating that into <whatever it is you're using> is left as an
> exercise.
>
> Why couldn't you just ask the straightforward question first?
Frankly, I wasn't even sure anybody would be reading -let alone
answering- this. I was doing the equivalent of "knock, knock: anyone
there?". As an Usenet pioneer, it saddens me to see how much its
quality has decreased over the years.
One reason for such "disprovement" is positive (NGs replaced by Google
search) and the other is negative (SPAM).
Having said that, the Perl NG seems to remain a useful place!
-Ramon
------------------------------
Date: Mon, 12 Oct 2009 11:21:29 -0700 (PDT)
From: Ramon F Herrera <ramon@conexus.net>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <1b686d31-3c44-4376-8408-218111fba31d@k33g2000yqa.googlegroups.com>
On Oct 12, 2:02=A0pm, J=FCrgen Exner <jurge...@hotmail.com> wrote:
> Ramon F Herrera <ra...@conexus.net> wrote:
>
>
>
> >> On Mon, 12 Oct 2009 07:48:54 -0700 (PDT), Ramon F Herrera <ra...@conex=
us.net> wrote:
> >> >> I have been able to come up with a regular expression which
> >> >> unequivocally matches any valid "statement" of such "language". See
> >> >> below.
> >(2) My future feature will be based on "quarters" instead of integers.
> >This is an instance of the most basic unit:
>
> >4/2008
>
> >(meaning the 4th. quarter of year 2008, of course).
>
> >Therefore the notation (I don't allow spaces, btw) will look like
> >this:
>
> >2/2000,3/2000,4/2000,1/2005,2/2005-1/2006
>
> >Which could be minimally expressed like this:
>
> >2/2000-4/2000,1/2005-1/2006
>
> >My failed attempt at dealing with calendar quarters is lifted entirely
> >from the integer version, but for some reasons it doesn't seem to
> >scale well.
>
> I will never understand the obsession involved with regular expressions.
> Of course you CAN use them to parse the above syntax, but why would you
> insist on doing so? Your syntax are so simple, a trivial
> =A0 =A0 =A0 =A0 split/,/
> will give you a sequence of ranges already, some of them representing
> single quarters. And that is all you need.
>
> And then just walk through them one by one and check if the beginning
> quarter of the next entry is one larger than the ending quarter of the
> current entry(*). If so then merge the two.
>
> *: this one is the only function that requires a tiny bit of
> intelligence. But as your data seems to be in chonological sequence you
> don't even have to deal with overlaps or included subsets or any of
> those things, that hit you when you least expect it.
>
> jue
Hi Jurgen,
The first thing they told me in CS classes was: "write general
functions, you never know when you are going to need a better
version". The input data (week sequences) is indeed going to be
provided by a program of mine (in the Windows client side, the current
problem is for the Linux serve side) BUT I will refuse to rely on it
being nicely ordered. I may hire another programmer at some point.
These expressions are going to become more complex as my software
deals with real-life data and I figured that starting with simple
integers would be a good start.
After the quarterly problem I intend to attack harder ones, such as
the dates in reverse order, its syntax and semantics.
My objective/goal is to sent the data from the client to the server in
the most succinct manner and to leave all heavy number crunching on
the server side (thin client).
Plus, this way I prevent Alzheimer or whatever similar stuff and keep
my programming brain in some sort of shape. I also study foreign
languages for absolutely no real reason.
-Ramon
------------------------------
Date: Mon, 12 Oct 2009 21:02:52 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <s3bcq6-269.ln1@news.rtij.nl>
On Mon, 12 Oct 2009 11:21:29 -0700, Ramon F Herrera wrote:
> The first thing they told me in CS classes was: "write general
> functions, you never know when you are going to need a better version".
Bad advice. Write what you need, with extendability in the back of your
mind.
> The input data (week sequences) is indeed going to be provided by a
> program of mine (in the Windows client side, the current problem is for
> the Linux serve side) BUT I will refuse to rely on it being nicely
> ordered.
Good. Always, ALWAYS, check your inputs.
> I may hire another programmer at some point. These expressions
> are going to become more complex as my software deals with real-life
> data and I figured that starting with simple integers would be a good
> start.
The algorithm by Jurgen is a very good aproach and gives you the
flexibility needed.
First read in your data to an intermediate format you can handle better,
then handle the data.
> After the quarterly problem I intend to attack harder ones, such as the
> dates in reverse order, its syntax and semantics.
Jurgens algorithm can handle all these, it becpomes a simple matter of
programming.
> My objective/goal is to sent the data from the client to the server in
> the most succinct manner and to leave all heavy number crunching on the
> server side (thin client).
With today's computing power even on most thin clients (I do know
exceptions) this reason is not the best of reasons. Having all validation
being done in one place, is a good reason, if possible. It may not be
possible, in fact it may be a good strategy to parse client side to give
friendly error messages to the user and parse server side to be
absolutely sure that you don't get fed rubbish in your database.
M4
------------------------------
Date: Mon, 12 Oct 2009 12:11:59 -0700 (PDT)
From: Ramon F Herrera <ramon@conexus.net>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <4ab94a28-a72d-4273-8511-5fe9f4c80ead@j19g2000yqk.googlegroups.com>
On Oct 12, 1:01=A0pm, Tim Landscheidt <t...@tim-landscheidt.de> wrote:
> Ramon F Herrera <ra...@conexus.net> wrote:
>
> > [...]
> > My failed attempt at dealing with calendar quarters is lifted entirely
> > from the integer version, but for some reasons it doesn't seem to
> > scale well.
>
> If you don't post it, we can't take a look at it (at least I
> do not believe in telepathy). If you post it, please do not
> use yet another grammar, but a valid Perl regular expres-
> sion, i. e. the output of "printf ("%s\n", sequence);" or
> something like it.
>
> Tim
Tim & Ben,
I believe the problem has been solved. Thanks for your kind
assistance. This is the 2nd. recent time I get stuck with a regex and
this is the 2nd time that the weird-looking "(?:" grouping operator
comes to my rescue.
I still have to run more comprehensive tests, but this is what I have
so far. In both "high level language" and "assembly language". :-)
It seems that the critical part was adding an "xterm" which is a
regular "term" surrounded by parentheses. For some reason, the Perl
expression provided by Ben does not require that set of parentheses.
-Ramon
--------------------------------
const string left_group =3D "(?:";
const string year_period =3D "[1-4]";
const string quarter =3D year_period + slash + year;
const string range =3D quarter + hyphen + quarter;
const string term =3D quarter + bar + range;
const string xterm =3D left_paren + term + right_paren;
const string sequence =3D xterm + left_group + comma + xterm +
right_paren + star;
sequence: ([1-4]/[12][0-9]{3}|[1-4]/[12][0-9]{3}-[1-4]/[12][0-9]{3})
(?:,([1-4]/[12][0-9]{3}|[1-4]/[12][0-9]{3}-[1-
4]/[12][0-9]{3}))*
------------------------------
Date: Mon, 12 Oct 2009 14:44:19 -0500
From: Tad J McClellan <tadmc@seesig.invalid>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <slrnhd70sh.6s8.tadmc@tadmc30.sbcglobal.net>
Ramon F Herrera <ramon@conexus.net> wrote:
> On Oct 12, 1:27 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>> Quoth Ramon F Herrera <ra...@conexus.net>:
>>
>>
>>
>>
>>
>> > (2) My future feature will be based on "quarters" instead of integers.
>> > This is an instance of the most basic unit:
>>
>> > 4/2008
>>
>> > (meaning the 4th. quarter of year 2008, of course).
>>
>> > Therefore the notation (I don't allow spaces, btw) will look like
>> > this:
>>
>> > 2/2000,3/2000,4/2000,1/2005,2/2005-1/2006
>>
>> > Which could be minimally expressed like this:
>>
>> > 2/2000-4/2000,1/2005-1/2006
>>
>> Right... so you want
>>
>> my $qtr = qr! [1234] / \d{4} !x;
>> my $range = qr! $qtr - $qtr !x;
>> my $item = qr! $qtr | $range !x;
>> my $expr = qr! $item (?: , $item )* !x;
>>
>> Translating that into <whatever it is you're using> is left as an
>> exercise.
>>
>
> > Why couldn't you just ask the straightforward question first?
>
> Frankly, I wasn't even sure anybody would be reading -let alone
> answering- this. I was doing the equivalent of "knock, knock: anyone
> there?".
How popular do you expect a newsgroup to be where half of all posts
are the equivalent of "knock, knock: anyone there?"?
> it saddens me to see how much its
> quality has decreased over the years.
Then do not contribute to the quality decrease with questionless questions.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.noitatibaher\100cmdat/"
------------------------------
Date: Mon, 12 Oct 2009 21:17:30 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <qffcq6-p6q2.ln1@osiris.mauzo.dyndns.org>
Quoth Ramon F Herrera <ramon@conexus.net>:
>
> I believe the problem has been solved. Thanks for your kind
> assistance. This is the 2nd. recent time I get stuck with a regex and
> this is the 2nd time that the weird-looking "(?:" grouping operator
> comes to my rescue.
(?: ) is equivalent to ( ) except it doesn't capture what it matches. If
you are only concerned about matching/non-matching, they are equivalent.
> It seems that the critical part was adding an "xterm" which is a
> regular "term" surrounded by parentheses. For some reason, the Perl
> expression provided by Ben does not require that set of parentheses.
qr// creates a compiled regex object. When one of these is interpolated
into another regex, it is surrounded by (?: ) so that it remains
self-contained. (Strictly, (?-xism: ), to preserve the flags that were
on the original qr//.)
> sequence: ([1-4]/[12][0-9]{3}|[1-4]/[12][0-9]{3}-[1-4]/[12][0-9]{3})
Hmm, I see you are already setting yourself up for y3k bugs...
Ben
------------------------------
Date: Mon, 12 Oct 2009 14:31:49 -0700 (PDT)
From: Ramon F Herrera <ramon@conexus.net>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <2947fae4-3ea2-4259-990d-52512ae46a88@v6g2000yqf.googlegroups.com>
On Oct 12, 4:17=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Ramon F Herrera <ra...@conexus.net>:
>
>
>
> > I believe the problem has been solved. Thanks for your kind
> > assistance. This is the 2nd. recent time I get stuck with a regex and
> > this is the 2nd time that the weird-looking "(?:" grouping operator
> > comes to my rescue.
>
> (?: ) is equivalent to ( ) except it doesn't capture what it matches. If
> you are only concerned about matching/non-matching, they are equivalent.
>
> > It seems that the critical part was adding an "xterm" which is a
> > regular "term" surrounded by parentheses. For some reason, the Perl
> > expression provided by Ben does not require that set of parentheses.
>
> qr// creates a compiled regex object. When one of these is interpolated
> into another regex, it is surrounded by (?: ) so that it remains
> self-contained. (Strictly, (?-xism: ), to preserve the flags that were
> on the original qr//.)
>
> > sequence: ([1-4]/[12][0-9]{3}|[1-4]/[12][0-9]{3}-[1-4]/[12][0-9]{3})
>
> Hmm, I see you are already setting yourself up for y3k bugs...
>
> Ben
Not to mention the fact that my program will fail to keep track of
invoices from the pre-Camelot era...
-Ramon
------------------------------
Date: Mon, 12 Oct 2009 14:39:22 -0700 (PDT)
From: Ramon F Herrera <ramon@conexus.net>
Subject: Re: Help needed with tough regular expression matching
Message-Id: <2b0af0d1-14cb-4ad0-bed5-dac161fc4964@s31g2000yqs.googlegroups.com>
On Oct 12, 4:17=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Ramon F Herrera <ra...@conexus.net>:
>
>
>
> > I believe the problem has been solved. Thanks for your kind
> > assistance. This is the 2nd. recent time I get stuck with a regex and
> > this is the 2nd time that the weird-looking "(?:" grouping operator
> > comes to my rescue.
>
> (?: ) is equivalent to ( ) except it doesn't capture what it matches. If
> you are only concerned about matching/non-matching, they are equivalent.
>
> > It seems that the critical part was adding an "xterm" which is a
> > regular "term" surrounded by parentheses. For some reason, the Perl
> > expression provided by Ben does not require that set of parentheses.
>
> qr// creates a compiled regex object. When one of these is interpolated
> into another regex, it is surrounded by (?: ) so that it remains
> self-contained. (Strictly, (?-xism: ), to preserve the flags that were
> on the original qr//.)
>
> > sequence: ([1-4]/[12][0-9]{3}|[1-4]/[12][0-9]{3}-[1-4]/[12][0-9]{3})
>
> Hmm, I see you are already setting yourself up for y3k bugs...
I have always said that the "Millennium Bug" is a complete misnomer.
- It is not a bug, but a choice
- It is not related to millennia, but to centuries.
It so happens that the very first change of centuries for computers
coincided with a millennium shift, but that was just a coincidence.
Next time humanity will face the problem will be in 2100.
-Ramon
------------------------------
Date: Mon, 12 Oct 2009 21:52:38 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: regexp assistance
Message-Id: <slrnhd7287.ueh.hjp-usenet2@hrunkner.hjp.at>
On 2009-10-12 13:36, Jürgen Exner <jurgenex@hotmail.com> wrote:
> mike <mikaelpetterson@hotmail.com> wrote:
>>I get files with another file extension than java.
>>
>>Is \z not to match at the end of a string?
>
> No, what gave you that idea?
> See 'perldoc perlre' and probably 'perldoc perlretut'.
Please open 'perldoc perlre' and search for \z.
hp
------------------------------
Date: Mon, 12 Oct 2009 14:06:38 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: regexp assistance
Message-Id: <3h67d55gqktmc4r3748m2q5bj1sf33du7f@4ax.com>
bugbear <bugbear@trim_papermule.co.uk_trim> wrote:
>Jürgen Exner wrote:
>> mike <mikaelpetterson@hotmail.com> wrote:
>>> /^.*Inds|Reset|Response\.java\z/s
>>
>> 'z' isn't special in a RE, therefore the backslash is redundant.
>>
>>> I get files with another file extension than java.
>>>
>>> Is \z not to match at the end of a string?
>>
>> No, what gave you that idea?
>
>It's in table 5.7 (Alphanumeric Regex Metasymbols) of the camel book!
I stand corrected. It is listed in perlre in the zero-width assertions
category.
jue
------------------------------
Date: Mon, 12 Oct 2009 21:46:17 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: time format +1 hour
Message-Id: <slrnhd71sa.ueh.hjp-usenet2@hrunkner.hjp.at>
On 2009-10-12 07:54, Josef Moellers <josef.moellers@ts.fujitsu.com> wrote:
> Peter J. Holzer wrote:
>> On 2009-10-09 07:13, Josef Moellers <josef.moellers@ts.fujitsu.com> wrote:
>>> Jürgen Exner wrote:
>>>> Slickuser <slick.users@gmail.com> wrote:
>>>>> I have this value:
>>>>> 20091008155222
>>>>> YYYY_MM_DD_HH_MM_SS
>>>>>
>>>>> Is there any module out there if I add 1 hour to my current timestamp,
>>>>> it will also roll over to DD, MM, and year if possible.
>>>>> This might happen at 23 hours (0-23), 0-6 days, 0-12 months..
>>>>>
>>>>> my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst) =
>>>>> localtime(time);
>>>> What's wrong with a simple
>>>>
>>>> my ($sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst)
>>>> = localtime(time + 3600);
>>> It will work in 99.99999% of all cases until you fall over one of these
>>> years where they add/subtract a leap second ;-)
>>
>> No. The unix time_t value ignores leap seconds. A day is always counted
>> as 86400 seconds (it wouldn't be possible to compute the time_t value
>> for future dates otherwise).
>
> These leap seconds are a PITA ;-)
> It probably depends upon what you define as being "one hour after":
> - 3,600 seconds later or
> - 1 hour later, but minutes and seconds identical.
>
> The unix time_t counts seconds since the epoch.
Yes and no. It defines "seconds since the epoch" differently than a
phycisist would. In
http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15
the explicit formula for converting calendar time (in UTC) into "seconds
since the epoch" is given, and it doesn't allow for leap seconds. This
is not an oversight, the text confirms:
| How any changes to the value of seconds since the Epoch are made to
| align to a desired relationship with the current actual time is
| implementation-defined. As represented in seconds since the Epoch, each
| and every day shall be accounted for by exactly 86400 seconds.
While I admit that the language of that section isn't as clear as the
formula, the fact is that all POSIX implementations implement the
formula as given and agree that 2008-01-01T00:00:00Z is 1199145600
"seconds since the epoch" and 2009-01-01T00:00:00Z is 1230768000
"seconds since the epoch", while in the real world there were 31622401
seconds between these two times, not 31622400.
Because "seconds since the epoch" are not really seconds since the epoch
in the physical sense I avoid the term and talk about a "POSIX time_t
value" instead.
> However, once you try to convert this into a human readable time
> onvolving years, months, days, hours, minutes, seconds, you *do* need
> to know leap days and seconds to do that.
You need to know about leap days of course, but these are fixed.
You do not need to know about leap seconds, since they aren't used in
this conversion. However, you do need to know about them for an accurate
implementation of difftime(). Strictly speaking,
difftime(1230768000, 1199145600) should return 31622401.0, but I doubt
there is any implementation which does.
> So, if you happen to want to know the time and date of *exactly* 1 hour
> after *exactly* 11pm on the 31st of december 2008, the answer depends
> upon the fact that 2008 had a leap second appended to the last minute of
> the year!
> If you just added 3,600 seconds to the time_t value of 12/31/2008
> 11:00:00pm, then you'd end up at 12/31/2008 11:59:60pm.
Yes, but there is no time_t value corresponding to that time: 1230767999
is 2009-12-31T23:59:59Z, and 1230768000 is 2009-01-01T00:00:00Z by
definition!
time_t value is implementation defined.
> But I must admit, this doesn't even help *me* and I'm not even sure any
> more that I am helping.
Just ignore leap seconds unless you need to make time measurements which
cannot tolerate a one second error. For "normal" calendar time keeping
you don't need to know about them.
However, daylight savings time is quite a different matter.
hp
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 2633
***************************************
