Help with a script..

Discussion in 'Perl Misc' started by clearguy02@yahoo.com, Apr 4, 2005.

  1. Guest

    Hi all,

    I have the below script ready to change a time stamp from
    15-Sep-04.01:03 to 2004-09-15 01:03:00.

    ===================================
    $date = '15-Sep-04.01:03';
    %months = qw(January 1 February 2 March 3 April 4 May 5 June 6 July 7
    August 8 September 9 October 10 November 11 December 12);

    $month_lookup = join '|', keys %months;
    if ( $date =~ /(\d+)-($month_lookup)-(\d+)\.(\d+):(\d+)/ )
    {
    $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    $months{$2}, $1, $4, $5);
    }
    print "$finalDate";
    ====================================

    Now my problem is that the $date variable might have 15-Sep-04.01:03 or
    15-Sept-04.01:03 or 15-September-04.01:03 (month will have a range from
    minumum first three chanracters to the whole month name).

    then how can I make sure that I can translate either Sep or Sept or
    September in to 09 in the final output?

    Thanks in advance,
    John.
     
    , Apr 4, 2005
    #1
    1. Advertising

  2. wrote in news:1112576321.475302.71500
    @z14g2000cwz.googlegroups.com:

    > $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    > $months{$2}, $1, $4, $5);


    As I noted before, there is a Y2.1K bug in there. When doing the right
    thing is just as easy as doing the wrong thing, why not do the right
    thing?

    > then how can I make sure that I can translate either Sep or Sept or
    > September in to 09 in the final output?


    What have you tried?

    Sinan

    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
     
    A. Sinan Unur, Apr 4, 2005
    #2
    1. Advertising

  3. Guest

    wrote:
    > I have the below script ready to change a time stamp from
    > 15-Sep-04.01:03 to 2004-09-15 01:03:00.


    > ===================================
    > $date = '15-Sep-04.01:03';
    > %months = qw(January 1 February 2 March 3 April 4 May 5 June 6 July 7
    > August 8 September 9 October 10 November 11 December 12);
    >
    > $month_lookup = join '|', keys %months;
    > if ( $date =~ /(\d+)-($month_lookup)-(\d+)\.(\d+):(\d+)/ )
    > {
    > $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    > $months{$2}, $1, $4, $5);
    > }
    > print "$finalDate";
    > ====================================


    > Now my problem is that the $date variable might have 15-Sep-04.01:03 or
    > 15-Sept-04.01:03 or 15-September-04.01:03 (month will have a range from
    > minumum first three chanracters to the whole month name).


    > then how can I make sure that I can translate either Sep or Sept or
    > September in to 09 in the final output?


    Well, you could just expand the hash %months...

    $date = '15-Sep-04.01:03';
    %months = qw(Jan 1 January 1 enero 1 Feb 02 Mar 03 Apr 04
    May 05 Jun 06 Jul 07 Aug 8 Sep 9 Sept 9 September 9
    Oct 10 Nov 11 Dec 12);

    if ($date =~ /(\d+)-(\w+)-(\d+)\.(\d+):(\d+)/
    && (my $mon = $months{$2})) {
    $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n",
    $3, $mon, $1, $4, $5);
    }
    print "$finalDate";

    Or without changing the hash, use the first three characters of the
    month supplied and reply on your data to be correct and not have,
    e.g. 'Sepulchre' present where the name of a month should occur,
    use something like...

    if ($date =~ /(\d+)-(\w+)-(\d+)\.(\d+):(\d+)/
    && (my $mon = $months{substr($2, 0, 3)})) {

    Axel
     
    , Apr 4, 2005
    #3
  4. A. Sinan Unur wrote:
    > wrote in news:1112576321.475302.71500
    > @z14g2000cwz.googlegroups.com:
    >>
    >> $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    >> $months{$2}, $1, $4, $5);

    >
    > As I noted before, there is a Y2.1K bug in there. When doing the right
    > thing is just as easy as doing the wrong thing, why not do the right
    > thing?


    What's "the right thing" when converting a 'DD-Mon-YY' date string?

    If it's a bug at all, isn't it rather a Y(-)x.yK bug?

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Apr 4, 2005
    #4
  5. On 04/04/2005, A. Sinan Unur wrote:

    > wrote in news:1112576321.475302.71500
    > @z14g2000cwz.googlegroups.com:
    >
    > > $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    > > $months{$2}, $1, $4, $5);

    >
    > As I noted before, there is a Y2.1K bug in there. When doing the
    > right thing is just as easy as doing the wrong thing, why not do the
    > right thing?
    >


    It's more than a Y2.1K bug:

    $shortyear = '04';

    could mean any of

    $longyear = '1904';
    $longyear = '2004';
    $longyear = '2104';

    etc.

    So doing the right thing is not as easy as some years ago, when we said
    e.g.

    $longyear = ($shortyear gt '50' ? '19' : '20') . $shortyear;

    --
    felix
     
    Felix Geerinckx, Apr 4, 2005
    #5
  6. Gunnar Hjalmarsson <> wrote in
    news::

    > A. Sinan Unur wrote:
    >> wrote in news:1112576321.475302.71500
    >> @z14g2000cwz.googlegroups.com:
    >>>
    >>> $finalDate = sprintf ("20%02d-%02d-%02d %02d:%02d:00\n", $3,
    >>> $months{$2}, $1, $4, $5);

    >>
    >> As I noted before, there is a Y2.1K bug in there. When doing the
    >> right thing is just as easy as doing the wrong thing, why not do the
    >> right thing?

    >
    > What's "the right thing" when converting a 'DD-Mon-YY' date string?


    "The right thing", it seems to me, would be to add the number of years
    to 2000 as a rule. In this particular case, with two-digit years the OP
    knows to be in this century, it probably does not matter, but IMHO, it
    is a good habit to get into.

    Sinan

    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
     
    A. Sinan Unur, Apr 4, 2005
    #6
  7. A. Sinan Unur wrote:
    > Gunnar Hjalmarsson wrote:
    >> What's "the right thing" when converting a 'DD-Mon-YY' date string?

    >
    > "The right thing", it seems to me, would be to add the number of years
    > to 2000 as a rule. In this particular case, with two-digit years the OP
    > knows to be in this century, it probably does not matter, but IMHO, it
    > is a good habit to get into.


    I'm still not with you.

    Aren't you mixing it up with how you should treat the sixth element
    returned by localtime() or gmtime() in list context? One typical Y2K bug
    in Perl programs was:

    my $year = (localtime)[5];
    $year = "19$year";

    while it should have been:

    $year = $year+1900;

    But the sixth element never was a two-digit year, even if it was treated
    as such in many programs. When converting two-digit years to four-digit
    ditto you *always* need to know in which century you are, don't you?

    --
    Gunnar Hjalmarsson
    Email: http://www.gunnar.cc/cgi-bin/contact.pl
     
    Gunnar Hjalmarsson, Apr 4, 2005
    #7
  8. Gunnar Hjalmarsson <> wrote in
    news::

    > A. Sinan Unur wrote:
    >> Gunnar Hjalmarsson wrote:
    >>> What's "the right thing" when converting a 'DD-Mon-YY' date string?

    >>
    >> "The right thing", it seems to me, would be to add the number of
    >> years to 2000 as a rule. In this particular case, with two-digit
    >> years the OP knows to be in this century, it probably does not
    >> matter, but IMHO, it is a good habit to get into.

    >
    > I'm still not with you.
    >
    > Aren't you mixing it up with how you should treat the sixth element
    > returned by localtime() or gmtime() in list context?


    I am not mixing it up, but that is what I am thinking of.

    > When converting two-digit years to four-digit ditto you *always*
    > need to know in which century you are, don't you?


    Yes, and in this case, the OP knows which century the data are from.
    However, the string concatenation approach, which he copied and pasted,
    again, IMHO, obscures that you are adding years to a base century (if that
    makes sense).

    Mine is just a warning against getting into the habit of string
    concatenation. Since the OP was using printf anyway, why not use

    # log files were generated after 2001
    printf "%4.4d", 2000 + $two_digit_year;

    Anyway, this is probably not wasting any more bits over. I see your point,
    and my attitude is appropriately softened on the issue.

    Sinan

    --
    A. Sinan Unur <>
    (reverse each component and remove .invalid for email address)

    comp.lang.perl.misc guidelines on the WWW:
    http://mail.augustmail.com/~tadmc/clpmisc/clpmisc_guidelines.html
     
    A. Sinan Unur, Apr 4, 2005
    #8
  9. On 2005-04-04, '' <> wrote in
    comp.lang.perl.misc:
    > Hi all,
    >
    > I have the below script ready to change a time stamp from
    > 15-Sep-04.01:03 to 2004-09-15 01:03:00.


    <snip>

    > Now my problem is that the $date variable might have
    > 15-Sep-04.01:03 or 15-Sept-04.01:03 or 15-September-04.01:03
    > (month will have a range from minumum first three chanracters
    > to the whole month name).
    >
    > then how can I make sure that I can translate either Sep or
    > Sept or September in to 09 in the final output?


    The Date::parse module on CPAN do what you want. Your original
    format [close enough to] one of the accepted formats for the
    str2time() function:

    $fmt_date = strftime( "...", localtime( str2time $date_str )

    Also look at the docs for the POSIX module, mainly strftime().

    Brandan L.
    --
    bclennox \at eos \dot ncsu \dot edu
     
    LaDainian Tomlinson, Apr 4, 2005
    #9
  10. On 05/04/2005, Abigail wrote:

    > Felix Geerinckx () wrote on MMMMCCXXXIV
    > September MCMXCIII in <url: news:>:
    > ~~ $shortyear = '04';
    > ~~
    > ~~ could mean any of
    > ~~
    > ~~ $longyear = '1904';
    > ~~ $longyear = '2004';
    > ~~ $longyear = '2104';
    > ~~
    > ~~ etc.
    >
    > Not in this case. The OP defined '04' to be 2004. Given that it's a
    > timestamp, 2104 isn't logical, as it's only 2005, and neither is 1904.
    > There was a shortage of computers in 1904.


    You are right, of course, but isn't it about making one's programs
    future proof?

    And speaking of dates, would you care to share why you stopped using
    the standard calendar in Sept 1993?

    --
    felix
     
    Felix Geerinckx, Apr 5, 2005
    #10
  11. "Felix Geerinckx" <> writes:
    > On 05/04/2005, Abigail wrote:
    >
    > > Felix Geerinckx () wrote on MMMMCCXXXIV
    > > September MCMXCIII in <url: news:>:
    > > ~~ $shortyear = '04';
    > > ~~
    > > ~~ could mean any of
    > > ~~
    > > ~~ $longyear = '1904';
    > > ~~ $longyear = '2004';
    > > ~~ $longyear = '2104';
    > > ~~
    > > ~~ etc.
    > >
    > > Not in this case. The OP defined '04' to be 2004. Given that it's a
    > > timestamp, 2104 isn't logical, as it's only 2005, and neither is 1904.
    > > There was a shortage of computers in 1904.

    >
    > You are right, of course, but isn't it about making one's programs
    > future proof?
    >
    > And speaking of dates, would you care to share why you stopped using
    > the standard calendar in Sept 1993?


    "The September that never ended." Look it up with Google.
     
    Arndt Jonasson, Apr 5, 2005
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,811
  2. Rajat
    Replies:
    3
    Views:
    705
    Jorgen Grahn
    Jan 8, 2010
  3. VYAS ASHISH M-NTB837
    Replies:
    2
    Views:
    565
    Jan Kaliszewski
    Jan 7, 2010
  4. Greg
    Replies:
    1
    Views:
    169
    Gunnar Hjalmarsson
    Jun 6, 2005
  5. Replies:
    9
    Views:
    176
Loading...

Share This Page