Re: [GT] genericdbi + sqlite : Date problem

[Robert A. S. <ra...@ac...>]

< snip >

> 
> Thanks Robert !
> As I wrote already in my answer to Thomas' hints (see the GT mail
> archive -- but not all messages are present there at the moment (?)  )

i don't see any messages from you to thomas and cc'ed in the gt-devel archive
so either the sf mailman doesn't like cc messages or you didn't cc the mail
list or ???

> I solved the problems by changing the --timeframe=day option so that
> the correct command is
> 
> ./graph --timeframe=year NZD_USD I:ADX

i'm thinking that doing that only 'side-steps' date-string format issue
in ../GT/DateTime.pm

> 
>  (Only) with this option it works and solves all error messages ! It is
> a similar thing as with the backtest moduls, which requires explicitely
> a
> --timeframe=day option to run.....
> 
> Concerning the population of the data base : I'm using a gnumeric
> spreadsheet with german data format (23.4.2013) as source and wrote a
> bash script which exports, cleans and imports the data to the sqlite3
> data base. The import command of sqlite3 checks the source data
> automatically, complains if the data of the specific field is not in
> an acceptable data format and converts it to the 2013/4/23 format
> without giving the user any choice.

ok, i've messed around with sqlite3 .import -- i've tried to enter
three date formats: YYYY/MM/DD,  YYYY-MM-DD and dd.mm.yyyy.

only YYYY-MM-DD is considered by sqlite3 to be a 'time-date' string.
the other forms are just text strings and cannot be converted using
the various date formatting provisions supported by sql and sqlite3.

the manual cut-paste commands i used to evaluate these are in the attached ...
and start near the bottom of the file after the line

hacking around with .import ...

you could still do the conversion in your version of ../GT/DB/generic.pm
on the prices arrays after they are output from the database ...

however, i think your best bet is to tweak your bash script to convert
your time-date strings into the YYYY-MM-DD format before you do the import.
you can easily do this with perl, sed and/or awk.
doing this will keep your GT code base consistent with the current version.

> So, I think the data format cannot be the reason for the timeframe
> problem

well it is actually -- if you look at the date decoding being done
just before line 285 in ../GT/DateTime.pm you will see the date is
split into 3 parts: day, month and year using the split character '-'.
in the timeframe 'day' mode when the split fails the month component
is undef, and -1 is passed to timegm as the month value which triggers
the error.

and before you start wanting to support other formats, we have
already evaluated this, and settled on using the ISO-8601 date format
standard as the primary date formats used internally.

we do however accommodate 'other' date formats (as recognized by primarily
Date::Manip) for command line inputs and similar (such as graphic
configuration files)

aloha

ras

 -- maybe its a matter of the localized versions my system
> uses as default for the date format (?).
> Anyway, I hope the problem is permanenly fixed by using the
> --timeframe=year option  ...
> Thx, delix
>