develooper Front page | perl.perl5.porters | Postings from January 2008

RE: This Week on perl5-porters - 20-26 January 2008

Thread Previous | Thread Next
From:
Jan Dubois
Date:
January 31, 2008 17:01
Subject:
RE: This Week on perl5-porters - 20-26 January 2008
Message ID:
012701c8646e$03696c80$0a3c4580$@com
On Thu, 31 Jan 2008, Jonathan Rockway wrote:
> Some of us were recently discussing this at a Perl Monger's meeting,
> and were confused as to when time_t enters the equation here. Let's
> say we want to know when your mortgage is paid off. We take the
> current time, and add 40 years:
>
>   my $expiry = time + years(40); # where years is 40*365*24*60*60
>
> OK, so now we have the expiry time, let's use DateTime to pretty-print
> it:
>
>   use DateTime; my $dt = DateTime->from_epoch(epoch => $expiry);
>
> $dt ends up being something like 2048-01-22T00:11:07, which is
> correct.
>
> So I guess my question is, when is time_t commonly involved in
> datetime operations? (I see the case where if it *is* 2038, and you
> ask the OS for the time you'll get the wrong answer. But it isn't
> 2038... according to my OS anyway :)

It comes into play because the other "builtin" functions belonging with
time() are localtime(), gmtime(), and the core module that does the
inversion functions Time::Local::timelocal() and Time::Local::timegm().

As a set, these functions have a 2038 problem on most 32-bit platforms.

Somewhat less critical right now, but also affected by time_t
limitations are stat() and utime().

Cheers,
-Jan


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About