localtime () - perl's bug ? 
Author Message
 localtime () - perl's bug ?

Hi,

I wrote a script in Perl that make's use of the localtime() command to
get the time and day as is wroten below:

#
($sec,$min,$hour,$day,$month,$year)=localtime ();
$data = "$day/$month/$year";
$horario = "$hour:$min:$sec";
#

But for my surprise the command works properly, but the month extracted
was ever one below the current. I tried it on my machine (INTEL), in a
DEC (alpha 500) and in the webserver (O2) and all reported the same
error.

Is it a perl's bug ?

[]s
SLepetys



Tue, 15 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?


=> Hi,
=>
=> I wrote a script in Perl that make's use of the localtime() command to
=> get the time and day as is wroten below:

=> #
=> ($sec,$min,$hour,$day,$month,$year)=localtime ();
=> $data = "$day/$month/$year";
=> $horario = "$hour:$min:$sec";
=> #

Ok, about 1 year and 1 month from now, you _do_ realize that code isn't
going to make a very nice date, don't you?

1/1/100

Hmmm....  You might want to pay more attention to all the y2k fuss. :)

=> But for my surprise the command works properly, but the month extracted
=> was ever one below the current. I tried it on my machine (INTEL), in a
=> DEC (alpha 500) and in the webserver (O2) and all reported the same
=> error.

Look back at the documentation for localtime...

...
    All array elements are numeric, and come straight out of a struct tm.
    In particular this means that $mon has the range 0..11 and $wday has
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    the range 0..6 with sunday as day . Also, $year is the number of
                                              **********************
    years since 1900, that is, $year is 123 in year 2023, and not simply
    **************** (Pay attention to this, too!!!)
    the last two digits of the year.
...

=> Is it a perl's bug ?

Nope, it's a sign of Perl's parentage...

It makes it slightly easier to do things like:


my $month  = $months[(localtime)[4]];
print "The current month is: $month\n";

Hope This Helps!

=> SLepetys

--Matthew



Tue, 15 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:

> Hi,

> I wrote a script in Perl that make's use of the localtime() command to
> get the time and day as is wroten below:

> #
> ($sec,$min,$hour,$day,$month,$year)=localtime ();
> $data = "$day/$month/$year";
> $horario = "$hour:$min:$sec";
> #

> But for my surprise the command works properly, but the month extracted
> was ever one below the current. I tried it on my machine (INTEL), in a
> DEC (alpha 500) and in the webserver (O2) and all reported the same
> error.

> Is it a perl's bug ?

I have seen these 'false alarms' many times.

Somehow, I fail to understand why people rather blindly believe they are
facing (Perl's) bugs instead of mistakes - their owned - before taking the
effort verifying it. <sigh>

My highest regards to those who have had the patience to provide the
clarification. In the meantime, Larry, I will try to do better.

-TK



Tue, 15 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?


Quote:
>Hi,

>I wrote a script in Perl that make's use of the localtime() command to
>get the time and day as is wroten below:

>#
>($sec,$min,$hour,$day,$month,$year)=localtime ();
>$data = "$day/$month/$year";
>$horario = "$hour:$min:$sec";
>#

>But for my surprise the command works properly, but the month extracted
>was ever one below the current. I tried it on my machine (INTEL), in a
>DEC (alpha 500) and in the webserver (O2) and all reported the same
>error.

>Is it a perl's bug ?

>[]s
>SLepetys

hey !

heres some code to use:

$timestamp = time();

sub get_date_string
{

  ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
localtime($timestamp);
  $mon++;
  $mon =  do date_pad($mon);
  $mday = do date_pad($mday);
  $hour = do date_pad($hour);
  $min =  do date_pad($min);
  $sec =  do date_pad($sec);
  ("${year}.${mon}.${mday}", "${hour}:${min}:${sec}");

Quote:
}

sub date_pad
{

  if ($n < 10) {
    return "0$n";
  }
  else {
    return "$n";
  }

Quote:
}

if this doesnt work, email me. it works on my machine.... but if you want to
print the local time its even easier:

print scalar localtime, "\n"; # thats also my favorite one line prog hehe




Wed, 16 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?
[Posted to comp.lang.perl.misc and copy mailed.]



Quote:


> >($sec,$min,$hour,$day,$month,$year)=localtime ();
> >$data = "$day/$month/$year";
> >$horario = "$hour:$min:$sec";

Y2K bug alert!

Quote:
> $timestamp = time();

> sub get_date_string
> {

>   ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) =
> localtime($timestamp);
>   $mon++;
>   $mon =  do date_pad($mon);
>   $mday = do date_pad($mday);
>   $hour = do date_pad($hour);
>   $min =  do date_pad($min);
>   $sec =  do date_pad($sec);
>   ("${year}.${mon}.${mday}", "${hour}:${min}:${sec}");
> }

Y2K bug alert!

Quote:
> sub date_pad
> {

>   if ($n < 10) {
>     return "0$n";
>   }
>   else {
>     return "$n";
>   }
> }

All this is much easier with sprintf -- almost a one-liner.  And you
want to use 'my' (not 'local'), and you do not need 'do' to call a
subroutine.

  $timestamp = time; # () superfluous for already defined function.

  sub get_date_string
  {
    my ($sec, $min, $hour, $mday, $mon, $year) = localtime shift;
    sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),
    sprintf('%.2d:%.2d:%.2d', $hour, $min, $sec);
  }

--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/



Wed, 16 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

: Hi,

: I wrote a script in Perl that make's use of the localtime() command to
: get the time and day as is wroten below:
<snip>
: But for my surprise the command works properly, but the month extracted
: was ever one below the current. I tried it on my machine (INTEL), in a
: DEC (alpha 500) and in the webserver (O2) and all reported the same
: error.

If you read
   perldoc -f localtime
you will see that $mday has a range from 0 to 11, ie. 0 is January.

: Is it a perl's bug ?

Nope.



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:

> sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

This look like a bug to me.  It prints "98.11.29", but the current year
is 1998, not 98.

--
Gareth Rees



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?
[Posted to comp.lang.perl.misc and copy mailed.]



Quote:

> > sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

> This look like a bug to me.  It prints "98.11.29", but the current year
> is 1998, not 98.

In the Jewish calendar, the current year is named 5769, commonly
referred to as 769, but neither of those *is* the current year, merely a
representation of its name.  Similarly, 1998 is not the current year,
nor is 98 -- they are merely representations of its name.

In the Gregorian calendar, the current year *is* a period of slightly
more than 365.25 rotations of the Earth relative to the Sun, beginning
when the Earth most recently reached a particular arbitrarily point in
its orbit around the Sun, which we designate as 1 January 00:00:00 UTC
or whatever (my current year started eight hours after yours did).

You may profit from a careful rereading of Lewis Carroll's little
discourse on epistemology and semantics in 'Through The Looking-Glass':

  'The name of the song is called "Haddocks' Eyes".'

  `Oh, that's the name of the song, is it?' Alice said, trying to feel
interested.

  `No, you don't understand,' the Knight said, looking a little vexed.
`That's what the name is called. The name really is "The Aged Aged Man"
.'

  `Then I ought to have said "That's what the song is called"?' Alice
corrected herself.

  `No, you oughtn't: that's quite another thing! The song is called
"Ways and Means": but that's only what it's called, you know!'

  `Well, what is the song, then?' said Alice, who was by this time
completely bewildered.

  `I was coming to that,' the Knight said. `The song really is "A-
sitting On a Gate": and the tune's my own invention.'

--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?
[Posted to comp.lang.perl.misc and copy mailed.]

Quote:

> sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

> This look like a bug to me.  It prints "98.11.29", but the current year
> is 1998, not 98.

> In the Jewish calendar, the current year is named 5769, commonly
> referred to as 769, but neither of those *is* the current year, merely a
> representation of its name.  Similarly, 1998 is not the current year,
> nor is 98 -- they are merely representations of its name.

You make my point more eloquently than I could make it myself.  Year
2000 bugs arise from choosing a naming system where a name can refer to
more than one year.

In the $year % 100 naming scheme, the name "98" refers to any of the
years named ..., 1898, 1998, 2098, ... in the (extended) Gregorian
calendar.  Determining which year is represented by the name "98" is in
general impossible, which is why programs using the system are buggy.

--
Gareth Rees



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:

>> sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

> This look like a bug to me.  It prints "98.11.29", but the current year
> is 1998, not 98.

Thats not a bug thats a deliberate design decision ;-P

/J\
--

Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:

>sub date_pad
>{

Sean, have you ever seen Perl's sprintf() function?

Do you know what the year field of the list returned from localtime is
in the year 2000? (Hint: Its not 2000, and its not 00)

Don't you worry about those "variable only used once" warnings when
you run the script with the "-w" flag?

(Do you run your scripts with the "-w" flag?)

sub get_date_string {
 my $timestamp = shift;

 ($sec, $min, $hour, $mday, $mon, $year) = (localtime $timestamp)[0 .. 5];

 return sprintf("%02d.%02d.%02d", $year % 100, $mon + 1 , $mday),
        sprintf("%02d:%02d:%02d", $hour, $min, $sec);

Quote:
}

--
Andrew Langmead


Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?
[Posted to comp.lang.perl.misc and copy mailed.]



Quote:
> > This look like a bug to me.  It prints "98.11.29", but the current year
> > is 1998, not 98.


> > In the Jewish calendar, the current year is named 5769, commonly
> > referred to as 769, but neither of those *is* the current year, merely a
> > representation of its name.  Similarly, 1998 is not the current year,
> > nor is 98 -- they are merely representations of its name.

> You make my point more eloquently than I could make it myself.  Year
> 2000 bugs arise from choosing a naming system where a name can refer to
> more than one year.

> In the $year % 100 naming scheme, the name "98" refers to any of the
> years named ..., 1898, 1998, 2098, ... in the (extended) Gregorian
> calendar.  Determining which year is represented by the name "98" is in
> general impossible, which is why programs using the system are buggy.

Two-word answer:    CONTEXT    CONVENTION

Longer answer:  Now you are confusing internal representation with
external representation.  This is the ultimate source of the socalled
Y2K bug.  Programmers relied on the CONTEXT of the problem domain to
supply the century, which is commonly omitted by CONVENTION.  They
assumed that the internal representation of the year as two digits would
be disambiguated by CONTEXT over the useful life of the program.

(Note that this is by and large still the case.  The bugs arise from
faulty calculations of the *interval* between two times, where the
program fails to supply the disambuguating CONTEXT correctly or at all!)

The CONTEXT of most problem domains is in fact severely bounded, so the
two-digit year CONVENTION for external representation is robustly
unambiguous.  In any case, the internal representation must be
appropriately unambiguous.

To put this in a Perl context -- the disambiguation:

    $year = ($year % 100 > 69 ? 1900 : 2000) + $year % 100
        if $year < 1970;

works fine for any program that relies on the Unix epoch for internal
date/time representation.  Programs which work in a historical or
astronomical CONTEXT must rely on a different internal date
representation, with different CONVENTIONs for external representation -
- be they BCE/CE years or MYBP (Millions of Years Before the Present).

--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:

>You make my point more eloquently than I could make it myself.  Year
>2000 bugs arise from choosing a naming system where a name can refer to
>more than one year.

No, year 2000 bugs arise from performing arithmetic on dates where the
date is not in a format to support calculations in the range needed.

I have some software that I wrote for my current company about 8 years
ago. It tracks data that will occur in the future. Once the day
specified passes, the data is no longer valid. The data is tagged with
a two digit year, but there is no Y2K problem. No calculations are
done to compare two pieces and find which is the greater or lesser
piece. The only calculation that is done is whether the month,
day-of-month, and the last two digits of the year match the values for
*today*.

It works now. It will continue to work for years. Its not worth
spending the time to change it.
--
Andrew Langmead



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?
[Posted to comp.lang.perl.misc and copy mailed.]



Quote:


> >> sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

> > This look like a bug to me.  It prints "98.11.29", but the current year
> > is 1998, not 98.

> Thats not a bug thats a deliberate design decision ;-P

What means the emoticon?  You are right on!  It took me many more words
to say the same thing.

--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/



Thu, 17 May 2001 03:00:00 GMT  
 localtime () - perl's bug ?

Quote:
> [Posted to comp.lang.perl.misc and copy mailed.]





>> >> sprintf('%.2d.%.2d.%.2d', $year % 100, $mon + 1, $mday),

>> > This look like a bug to me.  It prints "98.11.29", but the current year
>> > is 1998, not 98.

>> Thats not a bug thats a deliberate design decision ;-P

> What means the emoticon?  You are right on!  It took me many more words
> to say the same thing.

;-P is more of a na na na na na na schoolyard thing of light disaproval as
I see it.  A seriously meant point but i dont want the recipient to take it
too bad.

Anyhow George (er sorry) Gareth must see the point now - surely ...

/J\
--

Some of your questions answered:
<URL:http://www.btinternet.com/~gellyfish/resources/wwwfaq.htm>



Thu, 17 May 2001 03:00:00 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. localtime and Win32: The april fool's bug

2. localtime (perldoc -f localtime didn't help)

3. Bug with localtime() in Perl 5.004 and 5.005

4. localtime bug in activestate 805

5. bug in localtime()?

6. BUG in localtime(time)?

7. A bug in localtime()

8. bug in localtime()???

9. problem with function localtime, is it Y2K bug.

10. perl bug: perl -de '&{sub{}}'

11. why doesn't localtime()[2] work?

12. localtime(time) dosen't work

 

 
Powered by phpBB® Forum Software