[GT] Re: Re: package Finance::GeniusTrader::DateTime::Day;

[Josef Strobel <josef-strobel AT web.de>]

Hi ras and all,

For getting the right time zone POSIX has the functions tzname and tzset.
http://perldoc.perl.org/POSIX.html
http://www.opengroup.org/onlinepubs/009695399/functions/mktime.html
http://www.opengroup.org/onlinepubs/009695399/functions/tzset.html
So you can set it to GMT, CST ..., to everything you need. So what problem ocurred to joao costa?

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
>