Doom"s day at 2039 ?

# What can I do for years greater than 2038 and earlier that 1971 ?
# Windows operating system . I realy need this functionality.

use Time::Local;
printf "%s\n", scalar localtime timelocal(0,0,0,1,0,2038); # working
printf "%s\n", scalar localtime timelocal(0,0,0,1,0,2039); # not working
printf "%s\n", scalar localtime timelocal(0,0,0,1,0,1971); # working
printf "%s\n", scalar localtime timelocal(0,0,0,1,0,1970); # not working

Re: Doom"s day at 2039 ?

On Thu, 01 Dec 2005 00:52:00 +0200, George Bouras wrote:

> # What can I do for years greater than 2038 and earlier that 1971 ?
> # Windows operating system . I realy need this functionality.
>
> use Time::Local;
> printf "%s\n", scalar localtime timelocal(0,0,0,1,0,2038); # working
> printf "%s\n", scalar localtime timelocal(0,0,0,1,0,2039); # not working
> printf "%s\n", scalar localtime timelocal(0,0,0,1,0,1971); # working
> printf "%s\n", scalar localtime timelocal(0,0,0,1,0,1970); # not working

Use a DateTime object instead.

Dave...

Re: Doom"s day at 2039 ?

> Use a DateTime object instead.

It also explodes ...

The problem is starting to escalate the Perl bug scale.

Do not try to convince me that this is not a BUG.

Re: Doom"s day at 2039 ?

"George Bouras" wrote in message
news:dnaf6i$1i50$1@ulysses.noc.ntua.gr...
>> Use a DateTime object instead.
>
> It also explodes ...
>
> The problem is starting to escalate the Perl bug scale.
>
> Do not try to convince me that this is not a BUG.
>

It will be fixed when we all go to 64bit operating systems; it's not a bug
but a limitation of 32bit systems like Windows...

Matt

Re: Doom"s day at 2039 ?

"Matt Garrish" wrote in message
news:LB3mf.8945$kt5.685388@news20.bellglobal.com...
>
> "George Bouras" wrote in message
> news:dnaf6i$1i50$1@ulysses.noc.ntua.gr...
> >> Use a DateTime object instead.
> >
> > It also explodes ...
> >
> > The problem is starting to escalate the Perl bug scale.
> >
> > Do not try to convince me that this is not a BUG.
> >
>
> It will be fixed when we all go to 64bit operating systems; it's not a bug
> but a limitation of 32bit systems like Windows...
>
> Matt
>
>


Yes it is bug and bad design, since perl can handle big integers.
If it could not I could agree. Now it is bag by the design. I am wonder
how so many people overlook something so big for so long time, and
no one talks about.

Re: Doom"s day at 2039 ?

"NTUA" wrote in message
news:dnbc70$12o0$1@ulysses.noc.ntua.gr...
>
> "Matt Garrish" wrote in message
> news:LB3mf.8945$kt5.685388@news20.bellglobal.com...
>>
>> "George Bouras" wrote in message
>> news:dnaf6i$1i50$1@ulysses.noc.ntua.gr...
>> >> Use a DateTime object instead.
>> >
>> > It also explodes ...
>> >
>> > The problem is starting to escalate the Perl bug scale.
>> >
>> > Do not try to convince me that this is not a BUG.
>> >
>>
>> It will be fixed when we all go to 64bit operating systems; it's not a
>> bug
>> but a limitation of 32bit systems like Windows...
>>
>> Matt
>>
>>
>
>
> Yes it is bug and bad design, since perl can handle big integers.
> If it could not I could agree. Now it is bag by the design. I am wonder
> how so many people overlook something so big for so long time, and
> no one talks about.
>

How did you come to that silly assumption? Yes Perl can handle larger
values, but it doesn't handle them accurately. If you don't mind inaccurate
dates, then you're free to use something other than an int to store them.
The range you've hit, however, is the limit of a 32bit signed integer. It is
not a bug. Get over it.

Matt

Re: Doom"s day at 2039 ?

Realy !? Then how the hosting 32bit operating system can handle any date ?
This remember me a list of the top ten developer excuses.

Re: Doom"s day at 2039 ?

"NTUA" wrote in message
news:dnc3s3$fil$1@ulysses.noc.ntua.gr...
> Realy !? Then how the hosting 32bit operating system can handle any date ?
> This remember me a list of the top ten developer excuses.
>
>

Do you even know what epoch seconds are? Please figure out what is at issue
here...

Matt

Re: Doom"s day at 2039 ?

On Fri, 09 Dec 2005 01:20:59 +0200, George Bouras wrote:

>> Use a DateTime object instead.
>
> It also explodes ...

It doesn't if you use it correctly. You don't say what you did, so I can't
show you your error - but here's an example.

#!/usr/bin/perl

use strict;
use warnings;

use DateTime;

foreach (qw(2038 2039 1970 1971)) {
my $dt = DateTime->new(year => $_);
print $dt->datetime, "\n";
}

> The problem is starting to escalate the Perl bug scale.
>
> Do not try to convince me that this is not a BUG.

It's not a bug. As others have explained, it's a well-known limitation in
any programming language as a 32-bit integer to store dates and times.

DateTime.pm uses a different representation for dates and times and
therefore doesn't have this limitation.

Dave...

Re: Doom"s day at 2039 ?

On Sat, 31 Dec 2005 09:23:26 +0000, Dave Cross wrote:

> #!/usr/bin/perl
>
> use strict;
> use warnings;
>
> use DateTime;
>
> foreach (qw(2038 2039 1970 1971)) {
> my $dt = DateTime->new(year => $_);
> print $dt->datetime, "\n";
> }

Or for exactly the same output format as your original example, replace
the print line with

print $dt->strftime('%c'), "\n";


Dave...