Best regards
Josef
#!/usr/bin/perl
use POSIX;
print localtime() . "\n";
my $unixtime = POSIX::mktime(0, 0, 0, $mday, $mon, $year - 1900);
print $unixtime ."\n";
($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";
$ENV{'TZ'} = '';
POSIX::tzset();
print "New time/date: " . localtime() . "\n";
($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";
$ENV{'TZ'} = 'CST+06CDT';
POSIX::tzset();
print "New time/date: " . localtime() . "\n";
($std, $dst) = POSIX::tzname();
print "std $std\n";
print "dst $dst\n";
Am Mittwoch 18 November 2009 schrieb Robert A. Schmied:
josef et al
change history can sometimes be helpful to avoid repeating the same
mistakes again and again.
way way way back (24may2005) the methods 'map_date_to_time' called from
gt::datetime used to use posix::mktime(...) but that was changed when joao
costa found that "Posix::mktime returns GMT, while localtime returns,
well, local time" and that could (did, in fact) lead to conversion errors.
so the calls Posix::mktime(...)
were changed to
timelocal(...)
when one uses only an end-of-day (eod) database and doesn't use sub eod
timeframes this issue isn't a concern (at least i've not encountered it
and have not reverted to timelocal(...)).
i suspect the correct place to implement whatever fix is needed is where
the date-time value is first encountered. whether this is in the
gt::datetime package or some place else isn't something i've looked at
yet.
as to the issue of dates outside of the range 1970 .. 2038, is that really
much of a concern? from strictly an investing investors' viewpoint
something that happened over a few years ago isn't likely too relevant
now, certainly 30 years of history is adequate for investing purposes, but
maybe not for investing research. as for the upper end, it's still far
enough in the future so it isn't going to be a problem any time soon, and
by then the solution will likely be trivial.
as an aside, i note for users of flat file based prices data that gt
doesn't provide a way to limit the data read from these files (via the
$max_loaded_items argument and database $limit variable), but instead will
load the entire file. as these files increase in size (with lots of unused
data) the result is slower load times, longer processing times and higher
memory requirements than would be case for the same data set loaded from
one of the sql based database engines.
aloha
ras