extending from_epoch to years 2038

[Heiko Klein]

The DateTime module allows handling of a large range of dates, much 
larger than the standard unix epoch (from ~1901 to ~2038). This is 
really nice. But when calling the DateTime-from_epoch(epoch = 2**31) 
gives not 2038 as I hoped for, but 1901 due to an internal call to gmtime.


Since I'm working with predictions (of air pollution) up to year 2050 or 
even 2100, and several models save dates in epoch longlong seconds, I 
have to translate those large epoch seconds.


Some 64bit OSes start implementing a gmtime64 routine, but this is not 
(yet?) available in perl. As workaround, I use:


use constant SECSPERDAY = 24*60*60;
my $dateTime;
if (($epoch  (2**31 - 1)) || ($epoch  (-1 *(2**31 {
my $days = int($epoch / SECSPERDAY);
my $secs = $epoch - ($days*SECSPERDAY);
$dateTime = DateTime-from_epoch(epoch = $secs)-add(days = $days);
} else {
$dateTime = DateTime-from_epoch(epoch = $epoch);
}
print $dateTime, \n;

Wouldn't it be possible to implement this directly into the from_epoch 
routine. Caveats would be missing leap-seconds before 1901 and after 
2038. (Any more?) But at least dates up to year 5million would be possible.


Best regards,

Heiko

Re: extending from_epoch to years 2038

[Eugene van der Pijll]

Heiko Klein schreef:
 The DateTime module allows handling of a large range of dates, much 
 larger than the standard unix epoch (from ~1901 to ~2038). This is 
 really nice. But when calling the DateTime-from_epoch(epoch = 2**31) 
 gives not 2038 as I hoped for, but 1901 due to an internal call to gmtime.

Hi Heiko,

You may want to take a look at DateTime::Format::Epoch::Unix. It does not use
gmtime internally, and may therefore be slower than the from_epoch() method,
but it does return the correct results for the years you are interested in:

use DateTime;
use DateTime::Format::Epoch::Unix;

$dt = DateTime::Format::Epoch::Unix-parse_datetime(1e10);
print $dt\n

# output: 2286-11-20T17:46:40

If you work with even larger numbers, you can make DateTime::Format:Epoch use
Math::BigInt, but that is not necessary in your case.

 Wouldn't it be possible to implement this directly into the from_epoch 
 routine. Caveats would be missing leap-seconds before 1901 and after 
 2038. (Any more?) But at least dates up to year 5million would be possible.

At least in Unix, leap seconds are not counted, so that is not a problem in
your workaround.

Eugene